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(57) A public-key-encryption data-communication 
system includes a public-key-certificate issuer authority. 
The publiC'key-certificate issuer authority performs the 
issuance of a public key certificate and management op- 
erations, certification of a subject to be certificated, 
which is a certificate Issuing request, and management 
such as registration processing are executed by a root 
registration authority or each registration authority. The 
public-key-certificate Issuer authority performs process- 
ing for validating, invalidating, and deleting the certifi- 
cate In accordance with a request from the root regis- 
tration authority. The root registration authority accepts 
a request for issuing a public key certificate correspond- 
ing to the subject to be certificated which is under the 
control of a certificated registration authority, and trans- 
fers It to the public-key-certificate issuer authority in a 
form in which a signature is added to it. Processes by 
the public-key-certiflcate Issuer authority, the root reg- 
istration authority, the registration authority are separat- 
ed, whereby the need for new implementation of user 
recognition, certificate issuance, registration, and man- 
agement is eliminated. 
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Description 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

[0001] The present invention relates to public-key- 
certificate issuing systems for proving the validity of a 
public key for use in encrypted data transnnission in elec- 
tronic distribution systems, and data communication 
methods. In particular, the present invention relates to 
a public-key-certificate issuing system in which a data- 
transmission-service entity enables a public key and a 
publtc-key certificate to be used for general purposes 
without having a certificate authority function for issuing 
a public-key certificate, and to a data communication 
method. 

2. Description of the Related Art 

[0002] Nowadays, various types of software data 
(hereinafter refen^ed to as "contents"), such as game 
programs, audio data, image data^ and document-mak- 
ing programs, are distributed via networks such as the 
Intemet. Also, the purchase and sale of goods via a net- 
work, such as online shopping, has become gradually 
popular. 

[0003] In data communication of the above network 
type, in general, a data transmitting side and a data're- 
ceiving side transfer necessary data to each other after 
verifying that each side is correct, In other words, a data 
transfer system in which security is taken into consider- 
ation is formed. In a technique for realizing a security 
system in data transfer, encryption processing on data 
to be transferred and sign processing on data are per- 
fonmed. 

[0004] By decryption processing based on a prede- 
termined procedure, encrypted data can be restored to 
decrypted data (plaintext) that is usable. Data encryp- 
tion and decryption have been welt known in which an 
encryption key is used in encryption processing on the 
information and a decryption key is used in decryption 
processing. 

[0005] There are various types of data encryption and 
decryption using encryption and decryption keys. One 
example of the types is a so-called "public key encryp- 
tion". In the public key encryption, by using different keys 
for a transmitter and a receiver, one key is used as a 
public key that can be used by unspecified users, and 
the other key is used as a private key that is kept secret. 
For example, a data encryption key is used as a public 
key, and a decryption key is used as a private key. Oth- 
erwise, the public key encryption is used in a form that 
uses a certificator generating key as a private key and 
a certificator decrypting key as a public key. 
[0006] The public key encryption is advantageous to 
the management of keys since it differs from a so-called 
"synnmetric-key encryption method" using a symmetric 



key for decryption in that a particular person needs to 
have a private key that must be kept secret. However, 
since the symmetric-key encryption method has a slow- 
er data processing speed than that of the public key en- 

5 cryption, it is often used for small-data-amount objects 
such as a private key delivery, and digital signing. One 
typical example of the public key encryption is RSA 
(Rivest-Shamir-Aldleman) encryption. This uses the 
product of very large prime numbers (e.g., 150 digits), 

10 and uses difficulty of factorization processing on the 
product of the two large prime numbers. 
[0007] In the public key encryption, a technique is of- 
ten used which is designed allowing the general publk: 
to use a public key and which uses a public-key certifi- 

is cate certificating the validity of a distributed public key. 
For example, User A generates a pair of a public key 
and a private key, sends the generated public key to a 
certificate authority, and obtains a public-key certificate 
from the certificate authority. User A opens the public- 

20 key certificate to the public. By obtaining the public key 
from the public-key certificate by performing a predeter- 
mined procedure, an unspecified user encrypts a docu- 
ment or the like, and sends it to User A. User A is a 
system that uses the private key to decrypt the encrypt- 

25 ed document. User A is also a system that puts a sig- 
nature on the document by using the private key and 
that verifies the signature by obtaining the public key 
from the public-key certificate through a predetermined 
procedure. 

30 [0008] The p ub I ic- key certificate is described with ref- 
erence to Fig. 1 . The public-key certificate is a certificate 
issued by a certificate authority or an issuer authority, 
and is a certificate made such that, by submitting from 
a user the user's ID, a public key, etc, to the certificate 
35 authority, the certificate authority adds infomriation such 
as the ID of the certificate authority and a revocation 
date and also puts a certifk:ate authorit/s signature. 
[0009] The public-key certificate shown in Fig. 1 in- 
cludes a certificate version number, a certificate serial 
number assigned to a certificate user by the certificate 
authority, algorithm and parameters used for electronic 
signing, a certificate authority name, a certificate revo- 
cation date, a certifbate user name (user ID), a publk: 
key for the certificate user, and an electronic signature 
45 of the certificate user. 

[0010] The electronic signature is data generated by 
generating a hash value by applying a hash function to 
the entirety of the certificate version number, the certif- 
icate serial number assigned to the certificate user by 
so the certificate authority, the algorithm and parameters 
used for electronic signing, the certificate authority 
name, the certificate revocation date, the certif icate user - 
name, the entirety of the public key of the certificate us- 
er, and the electronic signature, and using a certificate- 
's authority private key on the hash value. 

[0011] The certificate authority issues the public key 
certificate shown In Fig. 1 , updates the public-key cer- 
tificate that has expired, and performs the generation, 
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management, and distribution (these are called "revo- 
cation") of an unauthorized person list for expelling us- 
ers who have taken unauthorized conducts. The certif- 
icate authority also generates a public key and a private 
key, as required. s 
[0012] When using the public-key certificate, a user 
uses the certificate authority public key retained by the 
user to verify the electronic signature on the public- key 
certificate, extracts the public key from the public-key 
certificate after succeeding in the verification of the elec- 
tronic signature, and uses the public key. Accordingly, 
all users who use the public-key certificate must retain 
certificate-authority public keys that are common. 
[0013] In a data transmission system based on the 
above-described public key encryption using a public- 
key certificate issued by a certificate authority, If a dif- 
ferent public key is used, it is required to newty request 
a certificate authority to issue a public-key certificate 
corresponding to the public key, or it is required to con- 
struct a certification system having a certificate authority 
function. In other words, for example, when a service 
provider that distributes contents or offers a goods pro- 
viding service starts a new service (new electronic dis- 
tribution system) and starts to use a new public key, the 
service provider always must request a certificate au- 
thority to perfomn the issuance and management of a 
public-key certificate corresponding to the new public 
key or to construct a certificating system having a cer- 
tificate authority system, so that problems occur in that 
a lot of costs and time are required. In addition, when 
certificates issued by different certificate authorities are 
used to perform communication, it is required, for veri- 
fying issuance authority signatures in the certificates, 
that a signature verifying key be acquired by establish- 
ing a link to a center, and this case is not suitable for 
offline use. 

SUMMARY OF THE INVENTION 

[001 4] Accordingly, it is an object of the present inven- 
tion to provide a public- key-encryption data-communi- 
cation system and data-communication method that 
simplify a public-key-certificate issuing system and that 
enable a service provider to easily use a publk:-key cer- 
tificate when a sen/ice provider starts a new service. 
[0015] To this end, according to an aspect of the 
present invention, the foregoing object is achieved 
through provision of a public- key-encryption data-com- 
munication system including a pubiic-key-certificate is- 
suer authority for issuing a public key certificate con^e- 
sponding to a subject to be certificated which perfomiing 
data transfer using public key encryption, a root regis- 
tration authority which executes mutual data transfer 
with the public-key-certificate issuer authority, which 
perfomns certification of the subject when the subject is 
under the control of the root registration authority and 
which requests the public-key-certrficate Issuer author- 
ity to issue the public key certificate corresponding to 



the subject, and a registration authority which executes 
mutual data transfer with the root registration authority, 
which performs certification of the subject when the sub- 
ject is under the control of the registration authority and 
which requests the root registration authority to issue 
the public key certificate corresponding to the subject. 
[0016] Preferably, in the public-key-encryption data- 
communication system, the root registration authority 
treats a plurality of registration authorities as subjects 
to be certificated, and each of the plurality of registration 
authorities treats, as a subject to be certificated, one of 
at least one service provider, at least one user terminal, 
and at least one user which are under the control of the 
registration authority. 

[0017] In the public-key-encryption data-communica- 
tion system, the registration authority or at least one 
service provider which is under the control of the regis- 
tration authority may apply, to a plurality of different serv- 
ices, a public key certificate corresponding to a subject 
to be certificated which Is under the control of the reg- 
istration authority or of the at least one service provider 
which is under the control of the registration authority. 
[0018] In the public-key-encryption data-communica- 
tion system, the root registration authority may include, 
as one of a plurality of registration authorities as sub- 
jects to be certificated which are under the control of the 
root registration authority, a clearing center for execut- 
ing settlement processing, and in processing using a 
public key certificate which is issued via the clearing 
center, settlement may be performed which relates to a 
service provided by a registration authority other than 
the clearing center which is under the control of the root 
registration authority or by at least one service provider 
which is under the control of the registration authority 
other than the clearing center. 

[001 9] In the public-key-encryption data-commu nica- 
tion system, the publte-key-certiflcate Issuer authority 
may hold a list of the correspondence among public 
keys and corresponding public key certificates, and the 
identifiers of subjects to be certificated for which the 
public key certificates are issued, and either the root reg- 
istration authority or the registration authority may hold 
entity data which conrespond to the subjects and which 
include certification data on the subjects. 
[0020] In the publlc-key-encryption data-communica- 
tion system, the public key certificates may each include 
an electronic signature field for an electronic signature 
of the public-key-certificate issuer authority, and a plu- 
rality of algorithms may be used as a signature algorithm 
for the electronic signature generated in the electronic 
signature field, and the public key certificates may each 
include a field identifying the used algorithm. 
[0021] In the public-key-encryption data-communica- 
tion system, in data transfer between the public-key-cer- 
tificate issuer authority and the root registration author- 
ity, cross certification processing may be performed, 
and when the cross certification is established, mutual 
data transfer may be executed. In data transfer between 
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the root registration autiiority and the registration au- 
thority, cross certification processing maybe performed, 
and when the cross certification is established, mutual 
data transfer may be executed, and in data transfer be- 
tween the registration authority and the subject, cross 
certification processing may be performed, and when 
the cross certification is established, mutual data trans- 
fer may be executed. 

[0022] In the public-key-encryption data-communica- 
tion system, between two among the public-key-certifi- 
cate issuer authority, the root registration authority, the 
registration authority, and the subject, data may be 
transferred in a fomn in which the data includes a gen- 
erated electronic signature of a data transmitting side. 
[0023] Preferably, in the public-key-encryption data- 
communication system, at least one of the root registra- 
tion authority and the registration authority possesses a 
revocation list conceming public key certificates corre- 
sponding to subjects which are under the control of the 
at least one, executes the updating of the revocation list, 
and requests the pubtic-key-certificate issuer authority 
to perform data processing conresponding to the updat- 
ing. 

[0024] In the public-key-encryption data-communica- 
tion system, at least one of the root registration authority 
and the registration authority may request the issuance 
of a plurality of public key certificates corresponding to 
a plurality of services which are under the control of the 
one authority. 

[0025] In the pub lie- key-encryption data-communica- 
tion system, the public key certificate may include a 
common electronic signature of the public-key-certifi- 
cate issuer authority which issues the public key certif- 
icate, and one of a root registration authority, a registra- 
tion authority, a service provider, and a user device 
which perform processing for the verification of one pub- 
Fic key certificate issued by the public-key-certificate is- 
suer authority may perform offline processing for the 
verification of different public key certificates issued by 
a single public-key-certificate issuer authority. 
[0026] In the public-key-encryption data-communica- 
tion system, the registration authority may be formed as 
a system holder as an authority whrch provides or man- 
ages a distribution Infrastructure for contents which are 
usable by a user terminal, contents for use in providing 
a sen/ice, or a service, and the system holder may con- 
trol and may treat a service provider and the user termi- 
nal as subjects to be certificated. 
[0027] Preferably, in the public- key-encryption data- 
communication system, the root registration authority 
controls a plurality of system holders which provide or 
manage an infrastructure for distributing different con- 
tents or services, receives a public-key-certificate issu- 
ing request via one of the system holders from one of at 
least one service provider and at least one user terminal 
which are under the control of the one system holder, 
and requests the publte-key-certiflcate issuer authority 
to issue a public key certificate. 



[0028] In the publlc-key-encryption data-communica- 
tion system, under the control of the system holder, the 
system holder may have contents creator which per- 
forms provision of contents by using a distribution infra- 

5 structure for contents or a service provided or managed 
by the system holder, and the system holder may treat 
the contents creator as a subject to be certificated. 
[0029] Preferably, in the publk;-key-encryptlon data- 
communication system, a user device which is under the 

10 control of a plurality of different system holders control- 
led by a common publlc-key-certiftcate issuer authority 
has a public key of the common public-key-certificate 
issuer authority. 

[0030] According to another aspect of the present in- 
15 ventfon, the foregoing object is achieved through provi- 
sion of a public-key-encryption data-communication- 
system fonning method including the steps of request- 
ing, by a subject to be certificated, a registration author- 
ity to Issue a public key certificate, transferring, from the 
20 registration authority to a root registration authority cer- 
tificating the registration authority, a public-key-certifi- 
cate issuing request from the subject, and transferring, 
from the root registration authority to a public-key-cer- 
tiflcate issuer authority certificating the root registration 
25 authority, the public-key-certif icate issuing request from 
the subject. 

[0031] Preferably, in the publlc-key-encryption data- 
communication-system forming method, the root regis- 
tration authority treats a plurality of registration author- 

30 ities as subjects to be certificated, and each of the plu- 
rality of registration authorities treats, as a subject to be 
certificated, one of at least one service provider, at least 
one user terminal, and at least one user which are under 
the control of the registration authority. 

35 [0032] In the public-key-encryption data-communica- 
tion-system forming method, the registration authority 
or at least one service provider which is under the con- 
trol of the registration authority may apply, to a plurality 
of different services, a public key certificate correspond- 

40 ing to a subject to be certificated which Is under the con- 
trol of the registration authority or of the at least one 
service provider which is under the control of the regis- 
tration authority. 

[0033] In the public-key-encryption data-communica- 
45 tion-system forming method, the root registration au- 
thority may include, as one of a plurality of registration 
authorities as subjects to be certificated which are under 
the control of the root registration authority, a clearing 
center for executing settlement processing, and in 
50 processing using a public key certificate which is issued 
via the clearing center, settlement may be performed 
which relates to a service provided by a registration au- 
thority other than the clearing center which is under the 
control of the root registration authority or by at least one 
55 service provider which is under the control of the regis- 
tration authority other than the clearing center 
[0034] In the public-key-encryption data-communica- 
tion-system forming method, the publte-key-certlfk;ate 
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issuer authority may hold a list of the correspondence 
among public keys and corresponding public key certif- 
icates, and the identifiers of subjects to be certificated 
for which the public key certificates are issued, and ei- 
ther the root registration authority or the registration au- 
thority may hold entity data which correspond to the sub- 
jects and which Include certification data on the sub- 
jects. 

[0035] In the public-key-encryption data-communica- 
tion-system fomning method, the public key certificates 
may each Include an electronic signature field for an 
electronic signature of the public-key-certificate issuer 
authority, and a plurality of algorithms may be used as 
a signature algorithm for the electronic signature gener- 
ated in the electronic signature field, and the public key 
certificates may each include a field identifying the used 
algorithm. 

[0036] In the public-key-encryption data-communica- 
tion-system forming method, in data transfer between 
the public-key-certiftcate issuer authority and the root 
registration authority, cross certifbation processing may 
be periormed, and when the cross certification is estab- 
lished, mutual data transfer may be executed. In data 
transfer between the root registration authority and the 
registration authority, cross certification processing may 
be periormed, and when the cross certification is estab- 
lished, mutual data transfer may be executed, and in da- 
ta transfer between the registration authority and the 
subject, cross certification processing may be per- 
fonmed, and when the cross certification is established, 
mutual data transfer may be executed. 
[0037] In the public-key-encryption data-communica- 
tion-system forming method, between two among the 
public-key-certificate issuer authority, the root registra- 
tion authority, the registration authority, and the subject, 
data may be transferred in a form in whbh the data in- 
cludes a generated electronic signature of a data trans- 
mitting side. 

[0038] Preferably, in the pub lie- key-encryption data- 
communication-system forming method, at least one of 
the root registration authority and the registration au- 
thority possesses a revocation list concerning public key 
certificates corresponding to subjects which are under 
the control of the at least one, executes the updating of 
the revocation list, and requests the public-key-certifi- 
cate issuer authority to perform data processing corre- 
sponding to the updating. 

[0039] In the publk:-key-encryption data-communica- 
tion-system forming method, at least one of the root reg- 
istration authority and the registration authority may re- 
quest the issuance of a plurality of public key certifk:ates 
corresponding to a plurality of services which are under 
the control of the one authority. 

[0040] In the public- key-encryption data-communica- 
tion-system forming method, the public key certificate 
may include a common electronic signature of the pub- 
lic-key-certificate issuer authority which issues the pub- 
lic key certificate, and one of a root registration authority. 



a registration authority, a service provider, and a user 
device which perform processing for the verification of 
one public key certificate issued by the public-key-cer- 
tificate issuer authority may perform offline processing 
5 for the verification of different public key certifk:ates is- 
sued by a single pubiic-key-certif icate issuer authority. 
[0041] In the public-key-encryption data-communica* 
tion-system forming method, the registration authority 
may be formed as a system holder as an authority which 
10 provides or manages a distribution infrastructure for 
contents which are usable by a user terminal, contents 
for use in providing a service, or a service, and the sys- 
tem holder may control and may treat a service provider 
and the user terminal as subjects to be certificated. 
[0042] Preferably, in the public-key-encryption data- 
communication -system forming method, the root regis- 
tration authority controls a plurality of system holders 
which provide or manage an infrastructure for distribut- 
ing different contents or services, receives a pubiic-key- 
certificate issuing request via one of the system holders 
from one of at least one service provider and at least 
one user terminal which are under the control of the one 
system holder, and requests the public- key-certiftoate 
issuer authority to issue a public key certificate. 
[0043] In the public-key-encryption data-communica- 
tion-system fomning method, under the control of the 
system holder, the system holder may have contents 
creator which perfomns provision of contents by using a 
distribution infrastructure for contents or a service pro- 
vided or managed by the system holder, and the system 
holder may treat the contents creator as a subject to be 
certificated. 

[0044] Preferably, in the public-key-encryption data- 
communication-system forming method, a user device 
which is under the control of a plurality of different sys- 
tem holders controlled by a common publte-key-certifi- 
cate issuer authority has a public key of the common 
public- key-certificate issuer authority. 
[0045] The present invention enables control of a root 
registration authority to perform certificate acquiring 
processing that is conventionally performed by each 
service provider, and enables, for example, control of a 
clearing center (payment RA) to perform credit control 
processing (user's credit inquiry) with banking facilities 
such as banks, whrch is executed for settlement caused 
by the distribution of contents, without controlling a pro- 
vider that perfomris contents distribution to perform the 
processing. In other words, aservrce provider that starts 
a new electronic distribution business can entrust the 
management of issuance of publk: key certificates to the 
root registration authority and the a publte-key-certifi- 
cate issuer authority, and can entrust settlement 
processing to another registration authority which is un- 
der the control of the root registration authority, whereby 
the service provider enables provision of service that us- 
es a user public key certificate by only periomiing user 
managing operations. 

[0046] Also the user managing operations can be en- 
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trusted to the root registration authority. A registration 
authority as a service provider can be designed to re- 
ceive user information, revocation information, etc., 
from the root registration authority, as required. 
[0047] In the present invention, a public-key-certifi- 5 
cate issuer authority perfomis Issuance of public key 
certlfteates and management operations, and user man- 
agement, such as processing of registering users who 
use public key certificates, is entrusted to a root regis- 
tration authority, whereby the need for executing user 
Identifying operations dependent on service contents is 
eliminated. Also revocation list management is per- 
formed by the root registration authority, and the public- 
key-certificate issuer authority perfonns only processing 
for validating, invalidating, and deleting the certif k:ate in 
accordance with a request from the root registration au- 
thority. 

[0048] As described above, in the present invention, 
processes by a public-key-certif bate issuer authority, a 
root registration authority, and a registration authority 
are separately performed, whereby, for each sen/ice, 
the Identification of a user, and the issuance, registra- 
tion, and management of public key certificates are not 
required to be newly configured in the same way as in 
a conventional system, whereby a new service using a 
public key and a public key certificate can be started by 
using existing data to configuring only necessary part. 
[0049] In the present invention, a public-key-certifi- 
cate issuer authority executes public-key-certif icate is- 
suing processing, and a root registration authority exe- 
cutes the management of users who use public key cer- 
tificates issued by the pubttc-key-certificate issuer au- 
thority. Accordingly, a public key certificate issued by the 
public-key-certificate issuer authority can be used in 
common in various services provided by a plurality of 
service providers (registration authorities orservrce pro- 
viders managed by the registration authority), whereby 
a service provider that will provide a new service does 
not need to configure a registration authority function. 
[0050] t n addition , since a public key certificate issued 
by a public- key-certificate issuer authority is based on 
a standard format, it is compatible with a public key cer- 
tificate issued by an existing registration authority, 
whereby it is possible to allow an existing system and 
the system of the present invention to exist in a mixed 
form. 

[0051 J According to the present invention , processes 
by a public-key-certificate issuer authority, a root regis- 
tration authority, and a registration authority are sepa- 
rately perfoimed, and for each service, the identification 
of a user, and the Issuance, registration, and manage- 
ment of public key certifteates are not required to be 
newly configured in the same way as in a conventional 
system, whereby a new service using a public key and 
a public key certificate can be started by using existing 
data to configuring only necessary part, whereby a load 
on the registration authority as in the conventional sys- 
tem can be reduced. 



[0052] According to the present invention, by forming 
a registration authority as a system holder that is an au- 
thority for providing or managing a contents or service 
distributing infrastructure for enabling provision of con- 
tents or services, certification and data communication 
using a common public key certificate can be executed 
between different infrastructures, and in a user device, 
the use of various services provided by different provid- 
ers, or cross certification processing with another user 
device can be executed using a common public key cer- 
tificate. 

[0053] Further objects, features, and advantages of 
the present invention will become apparent from the fol- 
lowing description of the prefen-ed embodiments with 
reference to the attached drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0054] 

Fig. 1 is an illustration of an example of a public key 
certificate; 

Fig, 2 is a block diagram showing an outline of pub- 
lic-key-encryption data-communication system of 
the present invention; 

Fig. 3 is an illustration (example 1) of processes by 
a public-key-certiftcate issuer authority, a root reg- 
istration authority, and a subject to be certificated in 
a public-key-encryption data-communfcation sys- 
tem of the present invention; 
Fig. 4 is an Illustration (example 2) of processes by 
a public-key-certificate issuer authority, a root reg- 
istration authority, and a subject to be certificated in 
a public-key-encryptton data-communk:ation sys- 
tem of the present invention; 
Fig. 5 is an illustration of the data structure of a pub- 
lic-key-certificate issuer authority in a public-key- 
encryption data-communication system of the 
present invention; 

Fig. 6 is an illustration (No. 1 ) of the structure of a 
public key certificate in a public- key-encryption da- 
ta-communication system of the present invention; 
Fig. 7 is an illustration (No. 2) of the structure of a 
public key certificate in a public- key-encryption da- 
ta-communication system of the present invention; 
Fig. 8 is an illustration of a data structure in the da- 
tabase of a registration authority in a public-key-en- 
cryption data-communication system of the present 
invention; 

Fig. 9 is an illustration (No. 1) of the structure of a 
revocation list in a public-key-encryption data-com- 
munication system of the present invention; 
Fig. 10 is an illustration (No. 2) of the structure of a 
revocation list in a pub lie- key-encryption data-com- 
munication system of the present invention; 
Fig. 11 is a flowchart illustrating sign generating 
processing applicable to a public-key-encryption 
data-communication system of the present inven- 
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tion; 

Fig. 12 is a flowchart Illustrating sign generating 
processing applicable to a public-key-encryptlon 
data-connmunication system of the present inven- 
tion; 5 
Fig. 13 is an illustration of cross certification 
processing applicable to a public-key/symmetrlc- 
key-encryption data-communication system of the 
present invention; 

Fig. 14 is an illustration of cross certification io 
processing applicable to a public-key-encryption 
data-communication system of the present inven- 
tion, - 

Fig. 15 is an illustration of tenms for use in a public-, 
key-encryption data-communication system of the is 
present invention; 

Figs. 16A and 16B are illustrations of pre-registra- 
tion processing between a public-key-certificate Is- 
suer authority and a registration authority in a pub- 
lic-key-encryption data-communication system of 20 
the present invention; 

Fig. 17 is an illustration of pre-registratton process- 
ing between a public-key-certificate issuer authority 
and a registration authority in a public-key-encryp- 
tion data-communication system of the present in- 25 
vention; 

Fig. 1 8 is an illustration of offline processing among 
a public-key-certifk:ate issuer authority, a registra- 
tion authority, and a user in a public-key-encryption 
data-communication system of the present inven- 30 

tion; 

Fig. 1 9 is an illustration of processing among a pub- 
lic-key-certificate issuer authority, a root registration 
authority, a registration authority, and a user in a 
public-key-encryption data-communication system 35 
of the present invention; 

Fig. 20 is an illustration of key updating processing 
among a public-key-certiftcate issuer authority, a 
root registration authority, and a service provider in 
a public-key-encryption data-communication sys- ^0 
tern of the present invention; 
Fig. 21 is an illustration of key updating processing 
among a public-key-certificate issuer authority, a 
root registration authority, and a service provider in 
a public-key-encryption data-communication sys- ^5 
tern of the present invention; 
Fig. 22 is an illustration of key revocation process- 
ing among a pub lie- key-certificate issuer authority, 
a root registration authority, and a user in a public- 
key-encryption data-communication system of the so 
present invention; 

Fig. 23 is an illustration of key-revocation validating 
processing among a public-key-certificate issuer 
authority, a root registration authority, and a user in 
a public-key-encryption data-communication sys- ss 
tem of the present invention; 
Fig. 24 is an Illustration of public-key-certificate de- 
leting processing among a public-key-certifk:ate is- 



suer authority, a root registration authority, and a us- 
er in a public-key-encryption data-communication 
system of the present invention; 
Fig, 25 is an illustration of a system holder and other 
authorities in a public-key-encryption data-commu- 
nication system of the present invention; 
Fig. 26 is an illustration of specific examples of a 
system holder and other authorities in a public-key- 
encryption data-communication system of the 
present invention; 

Fig. 27 is an illustration of an example in which a 
public key certificate is used when a system holder 
does not have a hierarchical structure with respect 
to a root registration authority; 
Fig. 28 is an illustration of an example in which a 
public key certificate is used when a system holder 
has a hierarchical structure with respect to a root 
registration authority; and 

Fig. 29 is an illustration of an example in which a 
public key certificate is used among a public-key- 
certificate issuer authority, a root registration au- 
thority, a registration authority, and a user in a pub- 
lic-key-encryption data -communication system of 
the present invention. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0055] Embodiments of the present invention are de- 
scribed below with reference to the drawings. 
[0056] In Fig. 2 is shown a schematic illustration of a 
data communication system and a data communication 
method that use public-key encryption. 
[0057] In Fig. 2, a shop 206, a terminal 207, a user 
device 208, and a user settlement organization 209 are 
subjects to be certificated, in other words, bodies that 
perform data transmission and reception based on pub- 
lic key encryption. Although Fig. 2 shows, as typical sub- 
jects to be certificated, one shop 206, one terminal 207, 
one user device 208, and one user settlement organi- 
zation 209, in general, many types of these exist, and 
other than these, various types of subjects to be certif- 
icated can exist. 

[0058] The shop 206, the tenninal 207, the user de- 
vice 208. and the user settlement organization 209 as 
subjects to be certificated, which are under control of 
each registration authority (also indicated by "RA" in the 
accompanying drawings), request registration authori- 
ties (service provider RAs) 203 and 204, and a registra- 
tion authority (payment RA) 205 to issue public-key cer- 
tificates corresponding to public keys they use. 
[0059] The registration authorities 203, 204, and 205 
certificate subjects (entities and apparatuses participat- 
ing in services) in services, or certificate a payer for par- 
ticipators in the services (guarantee for payment). The 
registration authority 203, 204. and 205 also receive is- 
suing requests on public-key certificates corresponding 
to publto keys used by the subjects (entities, apparatus- 
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es, and users participating in the services) in the serv- 
ices, and transfer them to a public-l<ey-certificate issuer 
authority (also Indicated by an "lA" in the accompanying 
drawings) 201 via a root registration authority (also in- 
dicated by a "root RA" in the accompanying drawings) 5 
202. The root registration authority 202 accepts the pub- 
lic-lcey-certificate issuing requests from the certificated 
registration authorities 203, 204, and 205. In other 
words, the root registration authority 202 accepts, as the 
publlc-lcey-certificate issuing requests, only requests 
from authorities certificated by the root registration au- 
thority 202. 

[0080] In Fig. 2, the registration authorities 203 and 
204 are, for example, service providers that perfomi pro- 
vision of services for distributing contents such as music 
data, image data, and game programs, and the regis- 
tration authority 205 is a clearing center that perfomns 
settlement processing on users' electronic money by 
perfonning data communication with the user settle- 
ment organization 209. These registration authorities 
shown in Fig. 2 are examples, and other than these, var- 
ious types of registration authortties that provide various 
services can exist. 

[0061] Each registration authority exists for each 
service (system), and the root registration authority 202 
exists as one that controls and certificates the registra- 
tion authorities. The root registration authority 202 is 
certificated by a public-key-certificate issuer authority 
201 , which is described below. The registration author- 
ities 203, 204, and 205 are small-sized service bodies. 
When the service providers do not have registration au- 
thorities for them, the root registration authority 202 can 
function instead of them. 

[0062] The public-key-certrficate issuer authority 201 
perfomis cross certification with the root registration au- 
thority 202 or the registration authority 203, 204 or 205, 
creates a public-key certificate based on a subject iden- 
tifier (ID) for identifying a subject as a public-key-certif- 
icate-issuance requesting body, a subject's public key, 
and other information to be written in the public-key cer- 
tificate, which are transferred from the root registration 
authority 202 or each of the registration authorities 203 
to 205, and distributes the public-key certificate to the 
registration authorities 203 to 205. 
[0063] This makes it a condition that the root registra- 
tion authority 202 or each of the registration authorities 
203 to 205, which requests the public-key-certificate is- 
suer authority 201 to issue a certificate, has been cer- 
tificated by the public-key-certificate issuer authority. 
[0064] Also, In response to a request from the root 
registration authority 202 or each of the registration au- 
thorities 203 to 205, the public-key-certifteate issuer au- 
thority 201 perfomns processing for responding to the 
updating, invalidation, and deletion of the public-key 
certificate, or to confimriation by the subject of the valid- 
ity of the public-key certificate. The public-key-certifi- 
cate Issuer authority 201 is to be authorized by an ap- 
propriate legal organization, and Is regarded as certifi- 



cated after being authorized. 

[0065] In Figs. 3 and 4 are illustrated processes in 
subjects to be certificated, such as the public-key-cer- 
tificate issuer authority 201 , the root registration author- 
ity 202 or the registration authorities 203 to 205, the 
shop 206, the tenninal 207, the user device 208, and 
the user settlement organization 209. 
[0066] Fig. 3 shows a case in which the subjects to 
be certificated, such as the shop 206, the terminal 207, 
the user device 208, and the user settlement organiza- 
tion 209 themselves generate public keys and private 
keys that are applied to the public key encryption. Fig. 
4 shows a case in which the root registration authority 
202 or the registration authorities 203 to 205 each gen- 
erate a public key and a private key. The service provid- 
ers 304 shown in Figs. 3 and 4 have no registration au- 
thority functions. 

[0067] Each process shown in Fig. 3 is described. The 
subject to be certificated 303 generates a public key and 
a private key that are applied to the public key encryp- 
tion, and requests the registration authority 302 to issue 
a certificate corresponding to the public key. At this time, 
the subject to be certificated 303 transmits its ID and the 
public key. Its ID is, for example, a user's own identifier, 
a user terminal Identifier, or the like. When receiving the 
Information, the registration authority 302 verifies the 
subject to be certificated, and subsequently transfers 
the received subject ID and public key to the public-key- 
certificate issuer authority 301 . The public-key-certifi- 
cate issuer authority 301 creates, based on the received 
subject ID and public key and on other infonnation to be 
written in the public-key certificate, the public-key cer- 
tificate, and distributes the certificate to the registration 
authority 302 via the registration authority or the root 
registration authority. The registration authority 302 
transfers the public-key certificate to the subject to be 
certificated 301. 

[0068] When executing updating processing after 
generating a new public key and a new private key, the 
subject to be certificated 303 transmits the newly gen- 
erated public key to the registration authority 302 with 
its ID. After verifying the subject to be certif bated 303, 
the registration authority 302 transfers the received sub- 
ject ID and public key to the public-key-certlflcate issuer 
authority 301 , the public-key-certificate Issuer authority 
301 creates a new public-key certificate based on the 
received subject ID and public key and on other infor- 
mation to be written in the public-key certificate, and 
transmits the certificate to the subject to be certificated 
via the registration authority or the root registration au- 
thority. 

[0069] As shown in Fig. 3, the registration authority or 
the root registration authority 302 performs verification 
processing on the subject to be certificated, and the 
holding of apparatus information and user information, 
and manages revocation of an issue by the public-key- 
certificate issuer authority 301 . 
[0070] The public-key-certlficate Issuer authority 301 
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perfoirns the management of the public key on the Is- 
sued public-key certificate and the ID of the subject to 
be certificated, processing for issuing a public-key cer- 
tificate, processing for invalidating the issued public-key 
certificate, and processing for checking the validity of 
the Issued public-key certificate. 
[0071 ] As for revocation proceedings, the public-key- 
certificate issuer authority 301 executes, based on a re- 
quest from the registration authority or the root registra- 
tion authority 302, processing for Invalidating the Issued 
public-key certificate. The registration authority or the 
root registration authority 302 notifies the subject to be 
certifk:ated 303 and the service provider 304, which 
needs revocation notification, of the revocation. The rev- 
ocation notification can be provided as difference data 
obtained by subtracting Invalidator data from the revo- 
cation data by the registration authority, which manages 
the revocation list, or the registration authority 302. 
[0072] The subject to be certificated 303 can request 
thd pubtk:-key-ceftificate issuer authority 301 to verify 
whether its public key is usable, in other words, whether 
the public-key certificate is valid. In this case, the subject 
to be certificated 303 transmits Its ID and the public key 
to the public-key-certificate Issuer authority 301 , and va- 
lidity verification is performed based on public keys and 
the IDs of subjects to be certificated which are managed 
by the public-key-certificate issuer authority 301 . 
[0073] Fig. 4 shows the case in which the registration 
authority or the root registration authority 302 generates 
the public key and the private key. In Fig. 4, the public 
key and the private key, generated by the registration 
authority or the root registration authority 302, are trans- 
mitted to the subject to be certif rcated 303, and the sub- 
ject to be certificated 303 stores them. The subsequent 
steps are similar to those in the processing in Fig. 3. 
[0074] Although the public-key-certificate revocation 
management In Figs. 3 and 4 is designed to be per- 
formed by the registration authority and the root regis- 
tration authority 302, the revocation management may 
be perfonned by the pub lie- key-certificate issuer author- 
ity 301. 

[0075] In Fig. 5 are shown main items of data man- 
aged by the publrc-key-certificate issuer authority 301 . 
"RAID" is an identifier for a registration authority to which 
a service is provided. "ID" is an identifier for a subject to 
be certificated. "PUBLIC KEY" is a public key for the 
subjectto be certificated, and "CERTIFICATE" is a pub- 
lic-key certificate itself. "VALIDITY FLAG" is a flag Indi- 
cating whether the publk:-key certificate is valid. 
[0076] In Figs. 6 and 7 is shown a format of a public- 
key certificate. This is an example based on Public Key 
Certificate Format X.509 Version 3. 
[0077] "version" Indicates the version of a certifbate 
format. 

[0078] "Serial Number" indicates the serial number of 
the public-key certificate which is set by the public-key- 
certificate issuer authority. 

[0079] "Signature algorithm Identifier algorithm pa- 



rameter" is a field in which a signature algorithm of the 
public-key certificate and its parameters are recorded. 
The signature algorithm Includes elliptic curve encryp- 
tion and RSA. When elliptk; curve encryption is applied, 

5 parameters and a key length are recorded, and when 
RSA is applied, a key length is recorded. 
[0080] "issuer* is a field in which an issuer of the pub- 
lic-key certificate, namely, the name of the public-key- 
certlflcate issuer authority Is recorded in a recognizable 

10 fomi (Distinguished Name). 

[0081] In "validity", a start date and time, and an end 
date and time are recorded which constitute a certificate 
validity period. 

[0082] In "subject", the name of a subject to be certif- 
15 icated, as a user, is recorded. Specificatiy, it is, for ex- 
ample, the ID of a user apparatus, the ID of a service 
providing body, or the like. 

[0083] "subject Public Key Info algorithm subject Pub- 
lic key" is a field for storing a key algorithm and key in- 

20 formation as user's public key infonmation. 

[0084] These fields are included in public- key-certifi- 
cate format X.509 Version 1 . The following are fields 
added In public- key-certificate fonnat X.509 Version 3. 
[0085] "authority Key Identifier-key Identifier, authori- 

25 ty Cert Issuer, authority Cert Serial Number" Is informa- 
tion for identifying a key to the public-key-certificate is- 
suer authority, and stores a key identifk;ation number 
(octal number), the name of the public-key-certificate is- 
suer authority, and an identification number. 

30 [0086] "subject key Identifier" stores an Identifier for 
Identifying each key when a plurality of keys are certifi- 
cated in the public-key certificate. 
[0087] "key usage" is a field which designates a use 
of a key, and in which one of uses: (0) digital signature, 

35 (2) key enciphenment, (1) non-repudiation, (3) data 
(message) encryption, (4) symmetric key transfer, (5) 
verification of a signature for certification, or (6) verifica- 
tion of signatures on the revocation list. 
[0088] In "private Key Usage Period", the effective 

40 date of a private key retained by the user Is recorded. 
[0089] In "certificate Policies", certificate Issuance 
policies of the certificate authority, or the public-key cer- 
tificate issuer authority and the registration authority are 
recorded. They mean, for example, a policy ID In ac- 

45 cordance with ISO/I EC 9384-1 , or a certificate standard. 
[0090] "policy Mapping" is a field used only when the 
CA (public-key-certificate issuer authority) is certificat- 
ed, and defines the policies of the public-key certificate 
issuer authority and the mapping of the policies to be 

50 certificated. 

* [0091] "supported algorithms" defines the attribute of 
a directory (X.500). This is used such that, when another 
system with which communication Is established uses 
directory information, its attribute is posted beforehand. 

55 [0092] "subject Alt Name" is a field in which another 
name of the user is recorded. 

[0093] "issuer Alt Name" is a field in which another 
name of the certificate issuer is recorded. 
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[0094] "subject Directory Attribute" is a field In which 
user's arbitrary attributes are recorded. 
[0095] "basic Constraint" is a field for determining 
whether the public key to be certificated is for signing by 
the certificate authority (public-key-certificate issuer au- 5 
thority) or is of the user. 

[0096] "name Constraints permitted Subtrees" Is a 
field indicating the effective range of a certificate used 
only when a subject to be certificated is the certificate 
authority (public-key-certificate issuer authority). io 
[0097] "policy Constraints" describes a specific certif- 
icate policy ID corresponding to the remainder of certif- 
icate paths, and a prohibition policy map. 
[0098] "Certificate Revocation List Distribution 
Points" Is a field to describe reference points of the rev- is 
ocation list (see Fig. 9) that is used to confimn whether 
the certificate has been revoked when the user uses the 
certifrcate. 

[0099] "signature" is a field for a signature of a public- 
key-certificate issuer (public-key-certificate Issuer au- 20 
thority). 

[0100] In Fig. 8, the data structure of an entity data- 
base In the registration authorities In Figs. 3 and 4 Is 
shown. The entity database Is designed to manage sub- 
jects to be certificated. 25 
[0101] "ID" is a field storing the identifiers of the sub- 
jects to be certificated. 

[0102] In "certificate data", infonmation required for 
certificating the subjects to be certificated, for example, 
user temiinal IDs when user terminals are to be certlfl- 30 
cated, etc., are recorded. 

[0103] In "certification results", last certification re- 
sults are recorded. 

[01 04] In "revocation infomiation", pointer Information 
to the revocation list are recorded. 35 
[0105] In Figs. 9 and 10 are shown fomiat examples 
(based on X.609 V2) of the revocation lists. Fig. 9 shows 
common items, and Fig. 1 0 shows infonnation managed 
by each certificate. Each item is described. 
[0106] "signature Algorithm Identifier" describes a 40 
signature algorithm about a signature to be applied. For 
example, it Is elliptic curve encryption or RSA. 
[0107] In "Issuer", the issuer of the revocation list Is 
recorded. In the examples in Figs. 3 and 4, the name of 
the registration authority Is recorded. 45 
[0108] In 'This Update", the issuance date and time 
of the revocation list Is recorded. 
[01 09] In "Next Update", the next date and time of the 
updating of the revocation list is recorded. 
[0110] In "Version", the version of the revocation list so 
Is recorded. 

[01 11 ] "authority Key Identifier-key Identifier, authori- 
ty Cert Issuer, authority Cert Serial Number" is infonna- 
tion for identifying a key to the public-key-certificate is- 
suer authority, and stores a key identification number ss 
(octal number), the name of the public-key-certificate is- 
suer authority, and a certificate number. 
[011 2] In "CRL Number", the issuance serial number 



of the revocation list Is recorded. 
[0113] In revocation list information ("Issuing distribu- 
tion point"), various types of information on the revoca- 
tion list are recorded: a distributor name ("Distribution 
point"), information ("only contains user certs") on 
whether the revocation list is used dedicatedly for sub- 
scriber revocation, infomiation on whether the revoca- 
tion list is used dedicatedly for revocation of the certifi- 
cate by the certificate authority (in this embodiment, the 
public-key-certificate issuer authority), and information 
("only some reasons") on whether there are other revo- 
cation reasons, and whether the revocation list is an in-f 
direct revocation list ("indirect CRL"). The indirect revo- 
cation list ("indirect CRL") is a fomi In which the man- 
agement of information on revocation reasons and the 
management of the revocation list are pertonmed by 
separate organizations. For example, in a case in which 
the root registration authority issues the revocation list, 
and the public-key-certificate issuer authority manages 
the public- key-certificate issuer authority, the form is de- 
fined as the indirect revocation list (indirect CRL). In this 
case, revocation infomiation storing points, for example, 
data that represent lA Identifiers are stored. According 
to the construction of the present invention, the revoca- 
tion list is generated as the indirect revocation list (indi- 
rect CRL), and the information on revocation reasons is 
managed not by a revocation list Issuer but by the public- 
key-certificate Issuer authority. 
[0114] In a CRL Identifier difference ("Delta CRL Indi- 
cator"), data on whether the revocation list Is distributed 
as a difference list are recorded. The difference list is a 
list structure in whrch public-key infonmation on deter- 
mined revocation, extracted from public-key infonnation 
on revocation options. Is designed to be providable to a 
related provider. 

[0115] Fig. 10 is an Illustration of Information man- 
aged by each certificate. 

[0116] In "certificate Serial Number", a certificate 
number is recorded. 

[01 17] In "Revocation Date", the date and time of ac- 
ceptance of an application for revocation is recorded. 
[01 1 8] The fields in so far are fields defined in version 
1 , and the following ones are fields defined in Version 2. 
[01 1 9] "Reason code" is a field to describe revocation 
reasons. Revocation reasons are as follows: 0: reason 
unknown; 1 : subscriber compromised; 2: CA (public- 
key-certificate issuer authority) key compromised; 3: 
certificate information has changed; 4: the certificate 
has got replaced; 5: suspension of use; 6: temporary 
suspension of use; and 7: release of temporary suspen- 
sion state. 

[0120] "Hold instruction code" describes a method of 
coping with the temporary suspension of use. 
[0121] "Invalidity date" describes a date and time at 
which the private key may have been damaged. 
[0122] "certificate issuer" describes the name of the 
certificate authority. However, in the case of the Indirect 
revocation list, revocation Infonnation is not managed 
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by the revocation list issuer authority. Accordingly, a 
designated revocation information management CA (e. 
g., the public-key-certificate issuer authority) is used to 
make a detour, in other words, a pointer to the lA is set. 
[0123] "signature" is a signature of the revocation list 
Issuer. 

[01 24] An electronic signature and cross certification 
processing, used in the public-key-certiflcate Issuing 
system and data communication method of the present 
invention, are described. After describing the electronic 
signature and cross certification processing, details of 
specific processing in the public- key-certificate issuing 
system of the present Invention are described below 
with reference to the drawings. 

Electronic Signature 

[01 25] A method of generating an electronic signature 
by using the public key encryption is described below 
with reference to Fig. 11 . The process shown in Fig. 11 
is a process flow of generating electronic signature data 
using EC-DSA ((Elliptic Curve Digital Signature Algo- 
rithm), IEEE P1363/D3). Here, an example that uses the 
Elliptic Curve Cryptography (hereinafter referred to as 
the ECC) as the public key encryption is described. In 
the data processing according to the present invention, 
in addition to the elliptic curve cryptography, for exam- 
ple, the RSA encryption ((Rivest, Shamir, Adleman), 
etc., (ANSI X9.31)) in a similar public key encryption 
may be used. 

[0126] The steps in Fig. 11 are described. In step SI , 
a characteristic Is represented by p, coefficients of an 
elliptic cun/e (elliptic curve: y2 = x^ -»- ax + b) are repre- 
sented by a and b, a base point on the elliptk; curve is 
represented by G, an order of G is represented by r, and 
a private key is represented by Ks (0 < Ks < r). In step 
S2, a hash value of message M is calculated, and it is 
assumed that f = Hash(M). 

[0127] Here, a method of finding a hash value by us- 
ing the hash function is described. The hash function is 
a function in which an input message is compressed into 
data having a predetermined bit length and the data is 
output as a hash value. The hash function has features 
in that it is difficult to predict an input from a hash value 
(output), in that many bits of the hash value are changed 
when one bit of data input to the hash function, and in 
that it is difficult to find out different Input data having the 
same hash value. As the hash function, MD4, MD5, 
SHA-1 , or the like, may be used, or DES-CBC may be 
used. In this case, l\^AC (check value: corresponding to 
ICV) that is used as a final output value becomes a hash 
value. 

[0128] Subsequently, in step S3, a random number u 
(0 < u < r) is generated, and in step S4, coordinates V 
(Xv, Yv) that is obtained by multiplying the base point by 
u times is cak^ulated. Addition and doubling on the ellip- 
tic curve are defined as follows: 



If P = (Xa. Ya). Q = (Xb, Yb), and R = (Xc, Yc) = P 
+ Q, when P Q (addition), 

Xc = X2 - Xa - Xb 
5 Yc = X X (Xa - Xc) - Ya 

A.= (Yb- Ya)/(Xb-Xa) 

when P = Q (doubling), 

Xc = X2 - 2Xa 
Yc = X X (Xa - Xc) - Ya 
X= (3(Xa)2 + a)/(2Ya) 

[0129] Using these, a value that is u times the point 
G Is calculated (although the speed is slow, the following 
is used as the most understandable operation method: 
G, 2 X G, and 4 X G are calculated, u is expanded in 
binary number, and corresponding 2* x G (a value ob- 
tained by doubling G i times (i Is a bit position counted 
from the LSB of u)) is added to a position having 1 . 
[0130] In step S5, c - Xvmod r is calculated, and in 
step S6, It Is determined whether this value is zero. If 
this value is not zero, d = [(f + cKs)/u] mod r is calculated 
in step 87, and It is determined in step S8 whether d is 
zero. If d is not zero, in step S9, c and d are output as 
electronic signature data. If it is assumed that r has a bit 
length of 1 60 bits, the electron^ signature data has a bit 
length of 320 bits. 

[0131] If c Is zero in step S6, the process proceeds 
back to step S3, and generates a new random number 
again. Similarly, if d is zero in step S8, the process pro- 
ceeds back to step S3, and generates a random number 
again. 

[0132] Next, a method of verifying the electronic sig- 
nature by using the public key encryption is described 
below with reference to Fig. 12. In step S11 , a message 
is represented by M, a characteristic is represented by 
p, coefficients of an elliptic curve (elliptic cun/e: y^ = x^ 
+ ax + b) are represented by a and b, a base point on 
the elliptic curve is represented by G, an order of G is 
represented by r, and G and Ks x G are used as a public 
key (0 < Ks < r). In step SI 2, It Is detemiined whether 
electronic signature data c and d satisfy 0 < c < r and 0 
< d < r. If these conditions are satisfied, in step S13, a 
hash value of the massage M is calculated, and it is as- 
sumed that f = Hash(M). Next, in step S14, h = 1/d mod 
r is calculated, and in step S15, h1 = fh mod r and h2 = 
ch mod r are calculated. 

[0133] In step SI 6, using the already calculated hi 
and h2, point P = (Xp, Yp) = h1 x G + h2-Ks x G is cal- 
culated. Since an electronic signature verifier knows 
public keys G and Ks x G, the verifier can perform cal- 
culation of multiplying a point on the elliptic curve by a 
scalar times, similariy to step S4 in Fig. 11. In step SI 7, 
it is determined whether the point P is a point at infinity. 
If the point P is not a point at infinity, the process pro- 
ceeds to step SI 8 (actually, determination on the point 
at infinity can be perfonned in step SI 6. In other words, 
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addition for P = (X, Y) and Q = (X, -Y) makes it Impos- 
sible to calculate X, and it is found that P + Q is a point 
at infinity). In step S18, Xp mod r is calculated, and is 
compared with electronic signature data c. When these 
values are finally identical, the process proceeds to step s 
SI 9, and determines that the electronic signature is cor- 
rect. 

[0134] If the process has detemnined that the elec- 
tronic signature is correct, the data is not manipulated, 
and it is found that a person who retains a private key 
corresponding to the public key has generated the elec- 
tronic signature. 

[01 35] if the electron ic signatu re data cord does not 
satisfy 0<c<rorO<d<r, the process proceeds to 
step S20. Also if the process has determined in step S1 7 
that the point P is a point at infinity, it proceeds to step 
S20. Also If the value of Xp mod r is not coincident with 
the electronic signature data c, the process proceeds to 
step S20. 

[0136] If the process has determined in step S20 that 
the electronic signature is not correct, it is found that the 
data is manipulated and it is found that a person who 
retains a private key corresponding to the public key has 
not generated the electronic signature. 

Cross Certification 

[0137] Between two means executing data transmis- 
sion and reception, after both verifies each other as a 
correct data communrcator, both transfer necessary da- 
ta to each other. Verification processing on whether both 
means are correct data communicators is cross certifi- 
cation processing. It is one preferred data transfer meth- 
od that, after the generation of a session key is per- 
formed in the cross certification processing, data trans- 
mission is performed executing encryption processing 
with the generated session key as a public key. 
[01 38] Cross certification using the public key encryp- 
tion is described below with reference to Fig. 13. In Fig. 
1 3, DES is used as the public key encryption, but a sim- 
ilar type of public key encryption may be used. 
[01 39] At first, "B" generates a 64-bit random number 
Rb, and transmits Rb and ID(b) that is an ID of itself to 
A. When receiving theses, "A" generates another 64-bit 
random number Ra, and uses key Kab in the CBC mode 
of DES to encrypt the data In the order of Ra, Rb, and 
ID(b), and sends the encrypted data back to B. 
[01 40] When receiving the encrypted data, B uses the 
key Kab to decrypt the received data. In a method of 
encrypting the received data, first, by using the key Kab 
to decrypt a ciphertext El, the random number Ra Is 
obtained. Second, by using the key Kab to decrypt a ci- 
phertext E2, and perfonning exclusive logical addition 
of the decrypted result and El , Rb is obtained. Finally, 
by using the key Kab to decrypt a ciphertext E3, and 
perfonning exclusive logical addition of the decrypted 
result and E2, ID(b) Is obtained. Among Ra, Rb, and ID 
(b) obtained as described above, B verifies whether Rb 
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and ID(b) are identical to those transmitted by B. If the 
verification is affirmative, B certificates that A is correct. 
[0141] Next, B generates a Session Key (hereinafter 
referred to as a Kses) that is used after the certification 
(the generating method uses a random number). B uses 
the key Kab in the CBC mode of DES to encrypt Rb, Ra, 
and Kses in the order given, and sends the encrypted 
data back to A. 

[0142] When receiving these, A uses the key Kab to 
decrypt the received data. Since a method of decrypting 
the received data is simitar to that performed by B, its 
details are omitted. Among Rb, Ra, and Kses obtained 
as described above, A verifies whether Rb and Ra are 
identical to those transmitted by A. If the verification is 
affirmative, A certifies that B is correct. After both certif- 
icate each other, the session key Kses is used as a sym- 
metric key for secret communication after the certifica- 
tion is performed. 

[0143] If incorrectness and inconsistency are found 
when verifying the received data, the cross certification 
is regarded as failing, and processing is discontinued. 
[0144] Next, a cross certification method using a 
1 60-bit elliptic curve encryption as a public-key encryp- 
tion method is described with reference to Fig. 14. In 
Fig. 14, ECC is used as a public-key encryption method, 
but a similar public-key encryption method may be used 
as described above. Also the key size may not be 1 60 
bits. In Fig. 14, first, B generates and transmits 64-bit 
random number Rb to A. When receiving it, A newly gen- 
erates 64-bit random number Rb and random number 
Ak smaller than characteristic p. A finds point Av = Ak x 
G, which is Ak times the base point G. and generates 
and sends electronic signature A.Sig corresponding to 
Ra, Rb, and Av (X coordinate and Y coordinate) back to 
B, with a public key certificate of A. Here, Ra and Rb 
each have 64 bits, and the X coordinate and Y coordi- 
nate of Av each have 160 bits. Thus, an electronic sig- 
nature corresponding to a total of 448 bits is generated. 
Since the electronic signature generating method has 
been described with reference to Fig. 11 , Its details are 
omitted. 

[0145] When using a public key certificate, the user 
uses a public key of the public-key-certificate issuer au- 
thority 410, whtoh Is retained by the user, to verify an 
electronic signature of the public key certifk;ate. After 
succeeding in the verification of the electronic signature, 
the user extracts the public key from the public key cer- 
tificate, and uses the obtained public key. Accordingly, 
all users who use the public key certificate must retain 
public keys of a common public-key-certificate issuer 
authority. Since the electronic signature verifying meth- 
od has been described with reference to Fig. 1 2, its de- 
tails are omitted. 

[01 46] Referring back to Fig. 2, the description Is con- 
tin ued. When receiving the public key certificate of A, 
Ra, Rb, Av, and the electronic signature A.Sig, B verifies 
whether Rb transmitted from A is identical to that sent 
by A. As a result, if the verification is affirmative, B uses 
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a public key of the certificate autliority to verify the elec- 
tronic signature in the public key certificate of A, and 
extracts the A's public key. B uses the extracted public 
key of A to verify the electronic signature A.SIg. Since 
the electronic signature verifying method has been de- 
scribed with reference to Fig. 12, its details are omitted. 
After succeeding in the verification of the electronic sig- 
nature, B certifies that A is correct. 
[0147] Nest, B generates random number Bk smaller 
than characteristic P. B finds point Bv = Bk x G, which 
is a value obtained by multiplying base point G by Bk 
times, and generates and sends electronic signature B. 
Sig that corresponds to Rb, Ra, and Bv (X coordinate 
and Y coordinate) back to A, with a publk: key certificate 
of B. 

[0148] When receiving the public key certificate of B, 
Rb, Ra, Av, and the electronic signature B.Sig, A verifies 
whether Ra transmitted by B is identical to that gener- 
ated by A. As a resuit, if both are identical, A uses the 
public key of the certificate authority to verify the elec- 
tronic signature in the public key certificate of B» and 
extracts the public key of B. A uses the extracted public 
key of B to verity the electronic signature B.Sig. After 
succeeding in the verification of the electronic signature, 
A verifies that B is correct. 

[0149] When both succeed in certification, B calcu- 
lates Bk X Av (although Bk is a random number, it is 
required to perform multiplication by a scalartlmes since 
Ay is a point on the elliptic curve), A calculates Ak x Bv, 
and the lower 64 bits of the X coordinates of these points 
are used as a session key for subsequent communica- 
tion (in a case In which the symmetric encryption is de- 
signed to symmetric encryption using a 64-bit key 
length). Definitely, the session key may be generated 
from the Y coordinates, and the lower 64 bits may not 
be used. In secret communication after the cross certi- 
fication, in addition to session-key encryption, an elec- 
tronic signature may be put on transmission data. 
[0150] When incorrectness and inconsistency are 
found in the verification of the electronic signature and 
the verification of the received data, the cross certifica- 
tion is regarded as failing, and the processing is discon- 
tinued. 

[0151] In the above-described cross certification 
processing, the generated session key is used to en- 
crypt transmission data, and mutual data communba- 
tion Is executed. 

[0152] In Fig. 15 is shown descriptions of terms that 
are used in the following description and that are related 
to the pubiic-key-certif icate Issuing system and the data 
communication method of the present Invention. These 
are briefly described. A key Is represented by K, P is 
added as a suffix to mean a public key. S is added as a 
suffix to mean a private key, and an owner Identifier (e. 
g., a) is added. A session key that is generated In cross 
certification for use In encryption and decryption 
processing Is represented by Ks. A public key certrfrcate 
of B, Issued by A, is represented by A«B». Concerning 



the encryption of data, for example, data encrypted us- 
ing the session key Ks is represented by EKs(data). Sim- 
ilarly, decrypted data is represented by D^sCdata). Con- 
cerning signature processing, for example, data signed 
5 using the private key Ksa of A is represented by {data} 
Sig-Ksa. Concerning encrypted signed data, what is ob- 
tained by using the session key Ks to encrypt "datailsig- 
nature" that is generated by signing data using the pri- 
vate key Ksa of A is represented by EKs({data)Sig-Ksa). 
[01 53] Figs. 1 6A and 1 6B show processes executed 
in the process of registering the root registration author- 
ity. Fig. 16A shows an online case, and Fig. 16B shows 
an offline case. Processing order is indicated by num- 
bers. The online case in Fig. 16A Is described. In the 
online case, between the root registration authority 1 601 
and the public-key-certificate issuer authority 1602, the 
cross certification described with reference to Figs. 1 3 
and 1 4 is executed using a pair of public keys of the root 
registration authority which are transferred to the root 
registration authority beforehand via another route 
which is not shown, whereby both recognizes each oth- 
er for communication, and the session key Ks is gener- 
ated. 

[0154] After the cross certification processing ends, the 
root registration authority 1601 generates its public key 
and private key, and requests the public-key-certif icate 
Issuer authority 1602 to Issue a publk: key certlTtcate cor- 
responding to the generated public key. The request for 
issuing the certificate is performed such that the root reg- 
istration authority 1601 transfers, to the public-key-certif- 
icate issuer authority 1602, EKs({RootRAID, Kp- 
RootRA'}sjg.KsRootRA) ^^^^ data encrypted using the 
session key Ks for the Identifier RootRAID of the root reg- 
istration authority 1601 and the public key KpRootRA' of 
the root registration authority 1601. 
[0155] After decrypting the received encrypted data 
EKs({RootRAID, KpRootRA*}sig.KsRootRA). and verifying 
the signature, the pub! te-key-certif Icate Issuer authority 
1602 stores the public key KpRootRA' of the root regis- 
tration authority 1601 as data to be managed in a data- 
base. In other words, the public-key-certificate issuer 
authority 1602 stores It as data in the database previ- 
ously described with reference to Fig. 5. 
[0156] In response to the certificate issuing request 
from the root registration authority 1601, the public-key- 
certlflcate issuer authority 1602 generates the public key 
certificate. This is a public key certificate in accordance 
with the fomiats in Figs. 6 and 7. The publte-key-certifi- 
cate issuer authority 1 602 stores the generated pubPic 
key certificate In the database for management (see Fig. 
5). Also, by signing the public key certificate of the root 
registration authority 1601 which is issued by the public- 
key-certiflcate Issuer authority 1602, namely, 
IA«RootRAx» by using the private key KsIA of the public- 
key-certificate issuer authority 1 602, and encrypting ft us- 
ing the session key Ks generated in the previous cross 
certification, the public- key-certlficate Issuer authority 
1 602 generates the data Ej^({IA« RootRA»}sig.KsjA)t 
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transmits the generated data to the root registration au- 
thority 1601. The root registration authority 1601 stores 
the transmitted data. Secret information both have in 
common beforehand may be a symmetric key. In this 
case, SigKsRootRA is an MAC value with the symmetric s 
key used. 

[01571 When the public-key-certificate issuer author- 
ity 1602 uses the registration authority to directly issue 
the public key certificate without using the root registra- 
tion authority, the processing is such that the root reg- 
istration authority 1601 in Fig. 16 Is replaced by the reg- 
istration authority. 

[0158] Fig. 16B shows an offline case in which the 
registering process is executed via a storage medium, 
for example, a DVD, a CD, a memory card, etc. In the 
offline process case, the processing is executed by stor- 
ing, In a storage medium, the information described 
about the offline process. 

[0159] Fig. 1 7 shows an example of a procedure per- 
formed when a registration authority 1701 perfomns the 
Issuance of a public key certificate In a case in which, 
under management by the root registration authority 
1 601 , there is the registration authority 1 701 , which op- 
erates as, for example, a service provider providing a 
service of distributing contents such as music data and 
image data, or as a service provider performing 
processing for electronic money settlement. The exam- 
ple is described in the order of the procedure. 
[01 60] First, cross certification processing is executed 
between the registration authority 1 701 and the root reg- 
istration authority 1601 . This is executed using, for ex- 
ample, cross certif ication keys (corresponding to the key 
Kab described with reference to Fig. 1 3) that are stored 
beforehand the memories of the registration authority 
1701 and the root registration authority 1601 . 
[01 61 ] Second, the registratton authority 1 701 signs the 
Identifier SPID of the registration authority 1701 using its 
private key K^sp, generates the data EKs({SPID}sig.KsSp) 
by performing encryption using the session key Ks gener- 
ated in the cross cert:ifk;ation, and transmits the generated 
data to the root registration authority 1 601 . After using the 
session key Ks to decrypt the received data and verifying 
the signature, the root registration authority 1 601 recog- 
nizes the signature and executes the signing of the recog- 
nition result, and performs encryption using the session 
key and executes recognition responding to the registra- 
tion authority 1 701 . 

[0162] When receiving the recognition response from 
the root registration authority 1601, the registration au- 
thority 1701 generates its publk: key and private key, 
signs the public key KpSP' using its private key, and en- 
crypts the signed public key using the session key to 
generate the data EKs({KpSp'}3|g.j<s3p). The registration 
authority transmits the generated data to the root regis- 
tration authority 1 601 . When receiving the data, the root 
registration authority 1 601 executes the requesting of 
the public-key-certifbate Issuer authority 1602 to Issue 
a public key certifk:ate of the registration authority 1 701 . 



Cross certification processing is performed between the 
root registration authority 1 601 and the public-key-cer- 
tlficate issuer authority 1 602. 

[0163] When certification is established in the cross 
certification processing, the root registration authority 

1 601 executes the signing of the identifier SPID of the 
registration authority 1 701 and the public key KpSp of 
the registration authority 1 701 by using the private key 
of the root registration authority 1601 . generates E^s 
({SPID, KpSP'}sig.KsRootsp) performing encryption 
using the session key generated in the cross certifica- 
tion, and transmits the generated data to the public- 
key-certificate issuer authority 1 602. 

[0164] The public-key-certificate issuer authority 

1602 decrypts the received data Eks((SPID, Kp- 
^P'Jsig-KsRootsp)' stores the public key KpSP of the 
registration authority 1 701 as management data in a da- 
tabase. In other words, it is stored as data in the data- 
base described with reference to Fig. 5. 

[01 65] The public-key-certificate issuer authority 1 602 
further generates a public key certificate of the registra- 
tion authority 1701. This is a public key certificate in ac- 
cordance with the fomriats in Figs. 6 and 7. The publlc- 
key-certificate issuer authority 1 602 stores the generated 
public key certificate In the database for management 
(see Fig. 5). The pub lie-key -certificate Issuer authority 
1602 also uses the private key KsIA of the public-key- 
certificate issuer authority 1 602 to sign the publb key cer- 
tificate of the registration authority 1701 , namely, IA«SP», 
which is issued by the public-key-certificate issuer au- 
thority 1 602, generates the data EKs({IA«SP»}sig.KsiA) by 
perfomning encryption using the session key Ks2 gener- 
ated In the cross certification processing, and transmits 
the generated data to the root registration authority 1 601 . 
The root registration authority 1 601 verifies the signature, 
uses its private key to perform sign the received data, and 
encrypts the signed data using a session key (the session 
key generated in the cross certification processing exe- 
cuted between the registration authority 1701 and the 
root registration authority 1 601 ). The root registration au- 
thority 1601 transmits the encrypted data to the registra- 
tion authority 1 701 . After using the session key to decrypt 
the received data, and verifying the signature, the regis- 
tration authority 1 701 stores the certificate. 
[01 66] In the above-described procedure, by omitting 
(5) the key generating process, the key that is embed- 
ded in a device of the registration authority 1701 may 
be used as a public key. In addition, by performing cross 
certification in which an initially embedded key is used 
as a symmetric key, a signature on (2) the data may be 
an MAC generated using the symmetric key. 
[0167] Fig. 18 illustrates a construction In which the 
process, which is described with reference to Fig. 17, of 
Issuing the public key certificate of the registration au- 
thority 1701 is executed in offline. The data transmitted 
between the authorities are processed such that they 
are exchanged using various storage media, for exam- 
ple, a DVD, a CD, a memory card, etc. In the offline proc- 
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ess case, the information tiiat is described about the of> 
f line process is stored in a storage medium for process- 
ing. 

[01 68] Fig. 1 9 shows an example of a procedure per- 
formed when a user 2001 (including a shop or the like) 
performs the issuance of a public key certificate in a 
case in which, under management by the registration 
authority 1 701 , there is a user who uses contents, a 
shop that sells contents, or the like. The example is de- 
scribed In the order of the procedure. 
[0169] In a device of the user 2001, the public key 
KpUD and private key KsUD of the user device, the pub- 
lic key KpRA of the registration authority 1 701 , and the 
public key KplA of the public-key-certificate issuer au- 
thority 1602 are embedded as initial embedded keys, 
for example, in a memory in an SAM (secure Application 
module). 

[0170] First, the user 2001 and the registration author- 
ity 1701 execute cross certification processing, and a 
session key is generated in the cross certification 
processing. This is performed using KpUD stored be- 
forehand in the user 2001 . 

[0171] Next, the user20O1 uses its private key K^uo 
to sign the identifier SAM ID of the user 2001 , generates 
the data Ej^5({SPID)sig.KsiA) performing encryption 
using the session key Ks generated in the cross certifi- 
cation, and transmits the generated data to the root reg- 
istration authority 1701 . The registration authority 1 701 
uses the session key Ks to decrypt the received data, 
recognizes the identifier SAMID, and executes signing 
processing on the recognition result. The registration 
authorrty 1701 also uses the session key to perform en- 
cryption, and executes recognition responding to the us- 
er 2001. 

[01 72] When receiving the recognition response from 
the registration authority 1701 , the user 2001 generates 
its public key and private key, uses its private key KsUD 
to sign the public key KpUD', and generates the data 
EKs({KpUD}sjn.KsiA) perfomiing encryption using the 
session key. The user 2001 transmits the generated da- 
ta to the registration authority 1701 . 
[0173] When receiving the data, the registration au- 
thority 1701 executes cross certification with the root 
registration authority 1601, and generates a session 
key. Next, the registration authority 1 701 uses its private 
key KsRA to sign the identifier SAMID and public key 
KpUD of the user 2001 , uses the session key Ks2 to 
encrypt the signed keys, and transmits the encrypted 
keys to the root registration authority 1 601 . 
[0174] The root registration authority 1601 performs 
decryption and verification processes by using the data- 
related session key transmitted from the registration au- 
thority 1 701 , and executes the requesting of the public- 
key-certificate issuer authority 1 602 to issue a certificate 
of the user 2001. In addition, the root registration au- 
thority 1 601 and the public-key-certificate issuer author- 
ity 1602 execute cross certification processing. 
[0175] When certifteatlon Is established in the cross 



certification processing, the root registration authority 

1 601 uses the private key of the root registration author- 
ity 1601 to execute the signing of the identifier SAMID 
and public key KpUD of the user 2001 , and generates 

5 Eks({SAMID, KpUD}sjg.KsRootsp) perfomning encryp- 
tion of the keys using the session key generated in the 
cross certification. The root registration authority 1601 
transmits the generated data to the pubPic-key-certifl- 
cate issuer authority 1602. 

10 [0176] After decrypting the received data E^gCiSA- 
MID, KpUD}sjg.KsRootsp)' verifying the signature, 
the public-key-certificate issuer authorrty 1602 stores 
the public key KpUD of the user 2001 as management 
data in the database. In other words, the publk:-key-cer- 

15 tif icate issuer authority 1 602 stores it as data in the da- 
tabase described with reference to Fig. 5. 
[0177] The public-key-certificate issuer authority 

1 602 further generates a public key certificate of the us- 
er 2001 . This is a public key certifk:ate In accordance 

20 with the formats In Figs. 6 and 7. The public-key-certif- 
icate issuer authority 1602 stores the generated pubik: 
key cert'ifk:ate in the database for management (see Fig. 
5). The public-key-certificate issuer authority 1602 also 
uses the private key KsIA of the pub lie- key-certificate 

25 issuer authority 1602 to sign the public key certificate, 
namely, IA«UD» of the user 2001, which is issued by 
the public-key-certificate issuer authority 1602, and 
generates the data EKs3({'A«UDs>}sig.KsiA) ^Y perform- 
ing encryption using the session key Ks3 generated in 

30 the cross certification processing. The public-key-certif- 
icate issuer authority 1 602 transmits the generated data 
to the root registration authorrty 1 601 , The root registra- 
tion authority 1601 verifies the signature, and uses its 
private key to sign the received data. The root registra- 

35 tion authority 1601 encrypts the signed data by using 
the session key (the session key generated in the cross 
certification processing executed between the registra- 
tion authority 1701 and the root registration authority 
1601), and transmits the encrypted data to the registra- 

40 tion authority 1 701 . The registration authority 1 701 fur- 
ther uses its private key to sign the received data, en- 
crypts the signed data by using the session key (the ses- 
sion key generated in the cross certification processing 
executed between the user 2001 and the registration 

45 authority 1 701 ), and transmits the encrypted data to the 
user 2001 . After decrypting the received data using the 
session key, and verifying the signature, the user 2001 
stores the certificate. 

[0178] In the above-described procedure, by omitting 
50 (5) the key generating process, the key embedded in 
the device of the user 2001 may be directly used as a 
public key. In addition, by perfomiing cross certification 
in which an initially embedded key is used as a symmet- 
ric key, a signature on (2) the data may be an MAC gen- 
55 erated using the symmetric key. 

[0179] Fig. 20 is an illustration of a procedure or up- 
dating processing in whteh a service provider as the reg- 
istration authority 1701 under management by the root 
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registration authority 1 601 generates a new public key 
and private key and perfomns issuance of a certificate 
of the newly generated public key. 
[0180] The registration authority 1701 generates a 
new public key and private key. Next, the registration 
authority 1 701 and the root registration authority 1 601 
execute cross certification processing. This can be ex- 
ecuted as cross certification processing using the 
present keys (the public key and the private key at the 
present time (before updating)), i.e., processing using 
asynnmetrk; key encryption described with reference to 
Fig. 14. 

[0181] Next, the registration authority 1701 uses its 
private key to sign the public key KpSP' that is newly 
generated by the registration authority 1701 , generates 
the data EKsH'^P^^'lsig-KsSp) Performing encryption 
using the session key generated in the cross certifica- 
tion processing, and transmits the generated data to the 
root registration authority 1 601 . When receiving the da- 
ta, the root registration authority 1 601 executes revoca- 
tion checking. The revocation checking is executed as 
the writing of pubfk: key data to be revoked in the revo- 
cation list described with reference to Figs. 9 and 10. 
[01 82] The root registration authority 1 601 further ex- 
ecutes the requesting of the public-key-certificate issuer 
authority 1 602 to issue a certificate of the registration 
authority 1 701 . In addition, the root registration authority 
1 601 and the public-key-certificate issuer authority 1 602 
execute cross certification processing. 
[0183] When certification is established in the cross 
certification processing, the root registration authority 

1 601 uses the private key of the root registration author- 
ity 1601 to sign the identifier SPID of the registration au- 
thority 1 701 and the public key KpSp of the registration 
authority 1701, generates Eks2({SPID, KpSp'}sig.KsRoot. 
3p) by performing encryption using the session key gen- 
erated in the cross certification processing, and trans- 
mits the generated data to the public-key-certificate is- 
suer authority 1602. 

[0184] After decrypting the received data Eks2({SPID, 
KpSp^sig-KsRootsp)' and verifying the signature, the pub- 
lic-key-certificate issuer authority 1 602 pertorms validity 
checking on the public key KpSP of the registration au- 
thority 1701. The validity checking is executed as 
processing in which, when the public key and public key 
certificate of the same user are stored in the database 
described with reference to Fig. 5, they are invalidated 
and a newly updated public key is validated. The public- 
key-certificate issuer authority 1 602 issues and regis- 
ters the newly updated public key certificate in the da- 
tabase. 

[0185] The public-key-certificate issuer authority 

1602 uses the private key KsIA of the public-key-certif- 
icate issuer authority 1602 to sign the generated public 
key certificate, namely, IA«SP», generates data Eks2 
({IA«SP»}sig.KsiA) perfomiing encryption using the 
session key Ks generated in the cross certification 
processing, and transmits the generated data to the root 



registration authority 1 601 . The root registration author- 
ity 1601 verifies the signature and uses its private key 
to sign the received data, and encrypts the signed data 
by using the session key (the session key generated in 

5 the cross certification processing executed between the 
registration authority 1 701 and the root registration au- 
thority 1 601 ). The root registration authority 1 601 trans- 
mits the generated data to the registration authority 
1 701 . After decrypting the received data using the ses- 

10 sion key, and verifying the signature, the registration au- 
thority 1 701 stores the certificate. 
[0186] Similarly to Fig. 20, Fig. 21 is an illustration of 
a procedure for issuing a new public key and private key 
certificate of a service provider as the registration au- 

15 thority 1 701 under management by the root registration 
authority 1601. However, in Fig. 21, the new public key 
and private key of the service provider are generated by 
the root registration authority 1601. 
[0187] Fig. 21 differs from Fig. 20 in steps (2) to (6). 

^ These steps are described. The registration authority 
1701 and the root registration authority 1601 execute 
cross certification processing. This is perfonned using 
cross certification keys (corresponding to the key Kab 
described with reference to Fig. 13) that are stored be- 

25 forehand in, for example, memories of the registration 
authority 1701 and the root registration authority 1601, 
or using the present public key and private key (see Rg. 
14). 

[01 88] Next, the registration authority 1 701 uses its pri- 

30 vate key K^p to sign the identifier SPI D of the registration 
authority 1701, generates data EKsH^PIDJsig.Kssp) by 
perfonning encryption suing the session key Ks generat- 
ed in the cross certification, and transmits the generated 
data to the root registration authority 1 601 . After using 

3s the session key Ks to decrypt the received data, and ver- 
ifying the signature, the root registration authority 1 601 
recognizes the Identifier SPID. Having recognized it, the 
root registration authority 1601 generates a new public 
key and private key of the root registration authority 1 601 . 

40 After that, the root registration authority 1 601 uses its pri- 
vate key to execute signing processing on the generated 
public key and private key of the registration authority 
1 701 , encrypts them using the session key, and transmits 
the encrypted keys to the registration authority 1 701 . The 

45 subsequent steps are similar to those in Fig. 20. 

[0189] Next, with reference to Fig. 22, revocation 
processing on a public key certificate is described. Al- 
though Fig. 22 shows the revocation processing as 
processes among the user 2001 , the root registration 

50 authority 1 601 , and the publk:- key-certificate issuer au- 
thority 1602, if there is the registration authority 1701 
between the user 2001 and the root registration author- 
ity 1601 , the registration authority 1701 affects commu- 
nication between the user 2001 and the root registration 

55 authority 1601. 

[0190] The processing in Fig. 22 is described. The 
root registration authority 1 601 pertonns processing for 
revocation when the pubPic key of the user 2001 is, for 
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example, unlawfully distributed, or In accordance with a 
request from the user 2001 . This Is executed as the 
process of adding the public-key infomiation of the user 
2001 to the revocation list described with reference to 
Figs. 9 and 10. The root registration authority 1601 per- 
forms registration to the revocation list, and requests the 
pubtic-key-certiflcate issuer authority 1602 to perform 
invalidation of the public key certificate. 
[0191] First, the root registration authority 1601 and 
the public-key-certificate issuer authority 1602 execute 
cross certification processing. When certification is es- 
tablished, the root registration authority 1601 uses the 
private key of the root registration authority 1 601 to sign 
the Identifier SAMISD of the user 2001, which con^e- 
sponds to a revoked public key, and the public key 
KpUD, generates Eks((SAMID. KpUD}sig.KsRootsp) by 
performing encryption using a session key generated in 
the cross certification, and transmits the generated data 
to the public-key-certificate issuer authority 1602. 
[0192] After decrypting the received data E^gHSA- 
MID, KpUD}sig.KsRootsp)> verifying the signature, 
the pub lie- key-certificate issuer authority 1602 performs 
Invalidation processing on the public key certificate cor- 
responding to the public key KpUD of the user 2001 . In 
other words, a flag in the database described with ref- 
erence to Fig. 5 is set to Indicate invalidation. The public- 
key-certificate issuer authority 1602 transmits, to the 
root registration authority 1601, data E^sHOK/ 
NG}sig.|^iA) obtained such that a response that Indi- 
cates whether the invalidation processing has been ex- 
ecuted (OK or NG) is signed and is encrypted using the 
session key. 

[0193] When the revocation processing on the public 
key certificate, which is consecutively performed, ends, 
the public key of the user 2001 is not allowed to be used 
under a service managed by the root registration author- 
ity 1 601 . In otherwords, transmission/reception and ver- 
ification of data encrypted using the public key cannot 
be performed with the root registration authority 1601, 
and also with another service provider managed by the 
root registration authority 1601, dealing using the re- 
voked public key is impossible. The root registration au- 
thority perfonns the differential distribution of the revo- 
cation list, as required. 

[0194] Fig. 23 illustrates the process of validating a 
revoked public key and a revoked public key certificate. 
When a public key is revoked, the user 2001 is denied 
(NG) access to the root registration authority 1601, 
When the root registration authority 1601 validates the 
revocation of the revoked public key, the root registra- 
tion authority 1601 issues a certifteate invalidating re- 
quest to the public-key-certificate issuer authority 1 602, 
and cross certification processing Is executed between 
the root registration authority 1601 and the public-key- 
certificate issuer authority 1602. 
[0195] When cross certification is established, the 
root registration authority 1601 uses the private key of 
the root registration authority 1 601 to sign the identifier 



SAMISD of the user 2001, which corresponds to the 
public key to be validated, and the public key KpUD, 
generates Eks({SAMID, KpUD}sjg.KsRootsp) by perfomn- 
ing encryption using a session key generated in the 

5 cross certification, and transmits the generated data to 
the public-key-certificate issuer authority 1602. 
[0196] After decrypting the received data E,^5({SA- 
MID, KpUD}s[g.KsRootsp). and verifying the signature, 
the public-key-certiflcate issuer authority 1602 performs 

10 the processing of validating the revoked public key cer- 
tificate corresponding to the public key KpUD of the user 
2001 . In otherwords, the flag in the database described 
with reference to Fig. 5 Is set to indicate validation. The 
public-key-certfficate issuer authority 1602 also trans- 

'5 rnits, to the root registration authority 1601, data E^s 
({OK/NG}sjg.KsiA) obtained such that a response that in- 
dicates whether the validation processing has been ex- 
ecuted (OK or NG) is signed and is encrypted using the 
session key. The root registration authority performs the 

20 differential distribution of the revocation list, as required. 
[0197] When the validation processing on the public 
key certificate, which is consecutively performed, ends, 
the publk: key of the user 2001 is allowed to be used 
under the service managed by the root registration au- 

25 thority1601. 

[0198] Fig. 24 is an illustration of the processing of 
deleting a public key certificate. In this case, the root 
registration authority 1 601 issues a certificate deleting 
request to the public-key-certiflcate issuer authority 

30 1 602 , and cross certif k^ation processing is executed be- 
tween the root registration authority 1 601 and the public- 
key-certificate issuer authority 1602. 
[0199] When cross certification is established, the 
root registration authority 1601 uses the private key of 

35 the root registration authority 1 601 to sign the identifier 
SAMISD of the user 2001, which corresponds to the 
public key to be deleted, and the public key KpUD, gen- 
erates Eks({SAMID, KpUD}sjg.KsRootSp) by perfomriing 
encryption using a session key generated in the cross 

40 certification, and transmits the generated data to the 
public-key-certificate issuer authority 1602. 
[0200] After decrypting the received data Ek3({SA- 
MID, KpUD)sig.KsRootsp). and verifying the signature, 
the publlc-key-certificate issuer authority 1 602 perfonns 

45 the processing of deleting the public key certificate cor- 
responding to the public key KpUD of the user 2001 . In 
other words, from the database described with refer- 
ence to Fig. 5, corresponding public-key Infonnation is 
deleted. The public-key-certificate issuer authority 1 602 

50 also transmits, to the root registration authority 1601, 
data EKs({OK/NG)sig.KsiA) obtained such that a re- 
sponse that indicates whether the deletion processing 
has been executed (OK or NG) Is signed and Is encrypt- 
ed using the session key. 

55 [0201] When the deletion processing on the public 
key certificate, which is consecutively performed, ends, 
the public key of the user 2001 is not allowed to be used 
under the service managed by the root registration au- 
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thority 1 601 . 

[0202] Next, an example of construction is described 
in which the registration authority is set as a system 
holder in a hierarchical structure composed of the root 
registration authority and the registration authority. 
[0203] The system holder is fomied by, for example, 
an authority that organizes and manages an Internet 
shop maricet on the Intemet, an authority that provides 
communication infrastructure for cellular phones, an au- 
thority that manages the use of cables for cable televi- 
sion, an electronic-money-card issuing body, or the like. 
In other words, the system holder is defined as an au- 
thority that provides and manages an infrastructure for 
distributing contents or services which enables provi- 
sion of various contents and services and that manages 
devices. 

[0204] In Fig. 25 is shown an illustration of the rela- 
tionship among a system holder 2501 , a contents crea- 
tor 2502, a service provider 2503, and a user 2504, and 
in Fig. 26 are shown specific examples of the system 
holder, the contents creator, the service provider, and 
the user device. 

[0205] In Fig. 25, the system holder 2501 provides an 
infrastructure for distributing contents and services that 
can be used in the contents creator 2502, the service 
provider 2503, and the user (device) 2504. The contents 
creator 2502 and the service provider 2503 provide con- 
tents or services by using the infrastructure provided by 
the system holder 2501. The user (device)2504 re- 
ceives a service provided by the service provider 2503 
by using the infrastructure provided by the system hold- 
er 2501 . 

[0206] In Fig. 26 are shown specific contents creator, 
service provider, and user device examples. As shown 
in Fig. 26, when the system holder is, for example, an 
intemet-shop-market organizer authority, the contents 
creator provides goods to be provided to the Internet 
shop market. The service provider is a shop that sells 
the provided goods in the Internet shop, and the user 
device is a PC or the like that uses the Internet shop. 
[0207] When the system holder is an authority that 
provides a cellular-phone communication infrastructure, 
such as a communication company or the like, the con- 
tents creator uses the cellular-phone communication in- 
frastructure to make and produce providable contents 
and goods. The service provider uses the cellular-phone 
communication infrastructure to sell and provide the 
contents and goods provided by the contents creator to 
users. In this case, the user device is a cellular phone. 
[0208] When the system holder is an authority that 
provides a cable television communication infrastruc- 
ture, such as a cable-televlsion-cabie-communicatlon 
management company, the contents creator uses the 
cable-television communication infrastructure to make 
and produce providable contents and goods. Also pro- 
grams that are provided to the cable television are in- 
cluded in the contents. The service provider uses the 
cable-television communication infrastructure to sell 



and provide the contents and goods provided by the 
contents creator to the users, and is, for example, a ca- 
ble television company that directly collects audience 
charges from viewers. 
5 [0209] When the system holder is an authority that 
provides electronic money settlement infrastructure, 
such as an electronic money issuing authority, the con- 
tents creator is a content and goods providing authority 
that provides goods that can be used (purchased) by 
10 electronic money, the service provider is a selling shop 
realized as a shop in which the contents and good pro- 
vided by the contents creator can be used using elec- 
tronic money. The user device is an IC card to which 
electronic money is input, or the like. 
IS [0210] In addition, there are various types of system 
holders, and depending on the type of system holder, a 
contents creator, a service provider, and a user device 
are formed. In other words, the system holder is defined 
as an authority that provides and manages a contents 
20 or service providing infrastructure enabling provision of 
contents and services usable by the user device. 
[0211] Here, a distribution constmction is described 
in which contents or services can be easily used for the 
users by controlling the system holder to implement the 
25 functions of the above-described registration authority. 
[0212] First, Fig. 27 is used to describe a public-key- 
cryptosystem distribution construction for contents or 
services in a form in whk:h the system holder is not pro- 
vided with the functions of the registration authority. 
30 [0213] As shown in Fig. 27, various types of services 
that can be used by the users exit. Each of the types 
uses its unique public key encryption, i.e., the issuance 
of a unique public key certificate that is effective only in 
a particular service by performing unique examination 
35 and unique registration, whereby the particular service 
is provided. Fig. 27 shows this conventional servk:e pro- 
viding construction. In Fig. 27 are shown a group 271 0 
that provides service A and a group 2720 that provides 
service B. 

40 [0214] The group 2710 that provides service A in- 
cludes a publlc-key-certificate Issuer authority (lA-A) 
271 1 that is usable for providing service A, a service pro- 
vider 2714 that requests the use of a public key certifi- 
cate, and a registration authority (RA-A) 2712 that exe- 
^ cutes the registration and management of a user (de- 
vice) 2715. Based on an examination by, for example, 
an official examination authority 2713, the registration 
authority 2712 performs, the registration of the service 
provider 2714 and the user (device) 271 5, requests the 
so public-key-certiffcate issuer authority (lA-A) 2711 to is- 
sue a certif teate, and perfomis the management of the 
service provider 2714 and the user (device) 2715. The 
public-key-certificate issuer authority (lA-A) 2711 and 
the registration authority (RA-A) 2712 constitute a cer- 
55 tificate authority (CA-A). 

[0215] The group 2720 that provides service B in- 
cludes a publlc-key-certificate issuer authority (lA-B) 
2721 that Is usable for providing servtee 8, a service pro- 
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vider 2724 that requests the use of a public key certifi- 
cate, and a registration authority (RA-B) 2722 that exe- 
cutes the registration and management of a user (de- 
vice) 2725. Based on an examination by, for example, 
an official examination authority 2723, the registration 
authority 2722 perfomis, the registration of the service 
provider 2724 and the user (device) 2725, requests the 
public-key-certificate issuer authority (lA-B) 2721 to is- 
sue a certificate, and performs the management of the 
service provider 2724 and the user (device) 2725. The 
pub lie- key-certificate issuer authority (lA-B) 2721 and 
the registration authority (RA-B) 2722 constitute a cer- 
tificate authority (CA-B). 

[0216] When, in this construction, the user 2715, to 
which a public key certificate usable in service A is is- 
sued by perfonming registration via the registration au- 
thority (RA-A) 2712 in order to be provided with service 
A, receives a sen/ice in service B, the issued public key 
certificate cannot be used. In order that the user 2715 
may receive a service in service it is essential to per- 
form a new registration procedure using the registration 
authority (RA-B) 2722 so that a new public key certifi- 
cate is issued. 

[0217] To solve this point, it is possible that certifica- 
tion be perfomned by both the certificate authorities 
(CAs) that are each composed of the public-key-certifi- 
cate issuer authority and the registration authority 
shown in Fig. 27, or it is possible that the certificate au- 
thorities (CAs) be formed to have a hierarchy. However, 
this causes a defect in a processing load in the certifi- 
cate authority increases and in that the certificate au- 
thority structure becomes complex. Otherwise, when a 
construction is employed in which a plurality of public 
key certificates corresponding to a plurality of services 
are stored in the device In order that the user may re- 
ceive the services, the storage area of the user device 
Is much used to store the public key certificates. This 
construction causes a problem in a device having a lim- 
ited storage area, such as an IC card. 
[0218] When both the user device 2715 and the user 
device 2725 in Fig. 27 perform cross certification in of- 
fline, both have different certificate authorities that con- 
trol them, the cross certification cannot be executed. In 
order that cross certification may be effectively execut- 
ed, both a public key of a certificate authority that con- 
trols a device Itself and a public key of a certificate au- 
thority that controls an associated device must be stored 
in the devices, so that the number of public keys to be 
stored increases more when certification with various 
associated devices is required. 
[0219] In the construction In Fig. 27 that perfonns in- 
dependent management for each service, various prob- 
lems occur. It is a construction shown In Fig. 28 in which 
each system holder is positioned at a hierarchy below 
each root registration authority that solves the problems. 
[0220] The construction In Fig. 28 is described. The 
construction in Fig. 28 corresponds to that in Fig. 27, 
and Includes a group of service providers in which the 



left one provides servk^e A and the right one provides 
service B. A service provider 2804 is a body providing 
service A, and a service provider 2807 is a body provid- 
ing service B. 

5 [0221] The service provider 2804, a user (device) 
2805, the service provider 2807, and a user (device) 
2808 are subjects to be certificated, namely, bodies that 
execute data transmission and reception using public 
key encryption. Although Fig. 28 shows the construction 

10 corresponding to two services A and B, many services 
can exist. 

[0222] The system holder A (2803) acts and functions 
as the above-described registration authority. The serv- 
ice provider 2804 and the user (device) 2805 as subjects 

15 to be certificated, which are underthe control of the sys- 
tem holder A, request the system holder A (2803) to is- 
sue public key certificates. The system holder B (2806) 
receives public-key-certificate issuing requests from the 
service provider 2807 and the user (device) 2808. 

20 [0223] Each of the system holder A (2803) and the 
system holder B (2806) certificates subjects (entities 
participating in service, apparatuses) in each service. 
Each of the system holder A (2803) and the system hold- 
er B (2806) receives a public- key-certificate Issuing re- 

25 quest about a public (entity participating in service, ap- 
paratus) key used by a subject in each service, and 
transfers it to a public-key-certificate issuer authority 
2801 via a root registration authority 2802. The root reg- 
istration authority 2802 accepts public-key-certificate is- 

30 suing requests from the system holder A (2803) and the 
system holder B (2806), which are certificated. In other 
words, the root registration authority 2802 receives a 
public- key-certificate issuing request when the request 
is from the system holder A (2803) or the system holder 

35 B (2806), which is certificated by the root registration 
authority 2802. 

[0224] In Fig. 28, the service provider 2804 and the 
service provider 2807 are service providers that execute 
provision of service for distributing contents such as mu- 
40 sic data, image data, and game programs, and are 
formed by the service providing bodies for providing var- 
ious services, which have been described with refer- 
ence to Fig. 26, 

[0225] The system holder A (2803) and the system 
45 holder B (2806) are authorities that manage infrastruc- 
tures for realizing the services provided by the service 
provider 2804 and the service provider 2807, and are 
fonned by the celtular-phone-communication Infrastruc- 
ture provider, the electronic-money/card issuing author- 
so ity, etc., which have been described with reference to 
Fig. 26. 

[0226] This embodiment is characterized in that a sys- 
tem holder that provides or manages an infrastructure 
for realizing provision of contents and provision of serv- 
55 ices operates as an interagent in public-key-certificate 
certification and Issuance of public key certificates of a 
data-communication implementing service provider and 
user device, and performs management of registration. 
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Since the system holder is an authority that provides or 
manages an Infrastructure for enabling provision of con- 
tents and provision of services, the system holder per- 
forms, in many cases, the management of users and 
service providers that use the infrastructure, and usually 
includes a management database. By using the man- 
agement database to also perform the management of 
public-key-certificate receivers, efficient management 
of users or service providers can be executed. 
[0227] When a new communication infrastructure is 
constructed, and a new system holder appears, by set- 
ting the new system holder to be under the control of an 
existing root registration authority and public-key-certif- 
icate issuer authority, a public-key-certificate issuing 
construction using the new infrastructure is easily real- 
ized, and provision of service using the new infrastruc- 
ture is realized. 

[0228] The user device can be controlled to use vari- 
ous services such that one public key certificate Is only 
stored in the user device. In other words, since in the 
construction in Fig. 2B, one root registration authority 
and one public-key-certificate issuer authority are set to 
correspond to the system holders and the service pro- 
viders, the user device can use different services by re- 
taining one public key certificate. In addition, between 
user devices which are underthe control of different sys- 
tem holders, cross certification can be pertomned using 
a public key issued by one common public-key-certifi- 
cate issuer authority. 

[0229] Next, Fig. 29 is used to describe a specific con- 
struction for the use of a public key certificate in the pub- 
lic-key-certificate issuing system and data communrca- 
tion method of the present Invention. 
[0230] The construction in Fig. 29 includes a public- 
key-certificate issuer authority 2901 for perfonming pub- 
lic key management and public- key-certificate issu- 
ance, an entity, namely, a root registration authority 
2902 for performing recognition processing for a subject 
to be certificated that requests issuance of a public key 
and a public key certificate, a service provider 2903 as 
a registration authority, a clearing center 2904, and a 
user terminal 2905. 

[0231] The registration authority 2902 is certifk^ated 
by the public-key-certificate issuer authority 2901 , and 
possesses a public key and private key of the root reg- 
istration authority 2902, and a public key certificate. A 
public key of the root registration authority 2902 and a 
public key of the public-key-certlflcate issuer authority 
2901 are posted to the service provider 2903 as a reg- 
istration authority which Is under the control of the root 
registration authority 2902, the clearing center (payment 
RA) 2904, and the user temninal 2905, or are embedded 
in each apparatus. 

[0232] The service provider 2903 and the clearing 
center 2904 register identifiers in the root registration 
authority 2902, and obtain public key certificates issued 
by the public-key-certificate issuer authority 2901 (proc- 
ess 2 shown). 



[0233] To receive a service from the service provider 
2903, the user terminal 2905 registers an apparatus by 
transmitting a unit identifier to the registration authority 
as the service provider 2903 via an SAM (Secure Appll- 
5 cation Module) of the user terminal 2905 (process 3 
shown). 

[0234] After verifying whether a user terminal identi- 
fied for a sen^ice provider (e.g., a service provider or 
shop not shown) by a unit identifier can use a service, 

10 the registration authority as the service provider 2903 
Issues a public key certificate via the publlc-key-certlfi- 
cate issuer authority 2901. The user terminal 2905 
stores the issued public key certificate in the SAM of the 
user terminal (denoted by 4 shown). These processes 

IS enable the user terminal 2905 to perform publfc-key da- 
ta communication in the system shown in Fig. 29 and to 
receive the provided service. 

[0235] To receive a service from the clearing center 
(payment RA) 2904, the user terminal 2905 registers an 
20 apparatus by transmitting a unit identifier to the regis- 
tration authority as the service provider 2903 via the 
SAM (Secure Application Module) of the user tenninal 
2905 (process 6 shown). 

[0238] When executing payment processing on con- 

25 tents charges by means of the clearing center 2904, us- 
ing electronic money stored In the user temnlnal's SAM, 
the user terminal 2905 registers the identifier of the user 
terminal 2905 in the clearing center 2904. 
[0237] The clearing center 2904 perfomns credit con- 

30 trol, etc., for a settlement authority such as a bank, iden- 
tifies a user (payer), and issues a public key certificate 
via the root registration authority 2902 and the public- 
key-certificate Issuer authority 2901 . The user terminal 
2905 stores the issued public key certificate in the user 

35 terminal's SAM (process 7 shown). 

[0238] When being provided with a service managed 
by the service provider 2903, the usertemiinal 2905 us- 
es the public key certificate received via the service pro- 
vider 2903. When using the service of the clearing cent- 

40 er 2904, or perfomns payment processing, the user ter- 
minal 2905 uses the public key certificate obtained by 
the clearing center 2904. 

[0239] When the clearing center2904 needs to direct- 
ly use the public key certificate transferred to the user 

45 temninal via the service provider 2903, the clearing cent- 
er 2904, publlc-key-certlflcate generating processing 
via the clearing center 2904 Is not perfonned, and by 
perfomning processing in both the clearing center 2904 
and the root registration authority 2902, an already gen- 

50 erated public key certificate is used as an effective pub- 
lic key certificate for settlement by the clearing center 
2904. 

[0240] As described above, the present invention has 
been fully described with reference to particular embod- 
55 iments. However, it is obvious that a person skilled in 
the art can modify or substitute the embodiments within 
the spirit of the present invention. In other words, the 
present invention has been disclosed in the form of em- 



20 



39 

bodiments, and should not be interpreted in a limited 
sense. To understand the spirit of the present invention, 
the appended Claims should be considered. 



Claims 

1. A public-l<ey-encryption data-communication sys- 
tem comprising: 

a pub lie- key-certificate issuer authority for issu- 
ing a public key certificate corresponding to a 
subject to be certificated, the subject perform- 
ing data transfer using public key encryption; 
a root registration authority for executing mutu- 
al data transfer with said public-key-certificate 
issuer authority, said root registration authority 
perfomning certification of the subject when the 
subject is under the control of said root regis- 
tration authority and requesting said public- 
key-certificate issuer authority to issue the pub- 
Ik: key certificate corresponding to the subject; 
and 

a registration authority for executing mutual da- 
ta transfer with said root registration authority, 
said registration authority performing certifica- 
tion of the subject when the subject is under the 
control of said registration authority and re- 
questing said root registration authority to issue 
the public key certificate corresponding to the 
subject. 

2. A public-key-encryption data-communication sys- 
tem according to Claim 1 , wherein: 

said root registration authority treats a plurality 
of registration authorities as subjects to be cer- 
tificated; and 

each of said plurality of registration authorities 
treats, as a subject to be certificated, one of at 
least one sen^ice provider, at least one user ter- 
minal, and at least one user whteh are under 
the control of the registration authority. 

3. A public-key-encryption data-communication sys- 
tem according to Claim 1 , wherein said registration 
authority or at least one service provider which is 
under the control of said registration authority ap- 
plies, to a plurality of different services, a publb key 
certificate corresponding to a subject to be certifi- 
cated whk:h is under the control of said registration 
authority or of said at least one service provider 
which is under the control of said registration au- 
thority. 

4. A public-key-encryptlon data-communication sys- 
tem according to Claim 1 , wherein: 



40 

said root registration authority includes, as one 
of a plurality of registration authorities as sub- 
jects to be certificated which are under the con- 
trol of said root registration authority, a clearing 
5 center for executing settlement processing; 

and 

in processing using a public key certificate 
which is issued via said clearing center, settle- 
ment is performed which relates to a service 

10 provided by a registration authority other than 

said clearing center which is under the control 
of said root registration authority or by at least 
one service provider which is under the control 
of said registration authority other than said 

15 clearing center. 

5. A public-key-encryption data-communication sys- 
tem according to Claim 1 , wherein: 

20 said pubric-key-certificate issuer authority 

holds a list of the correspondence among publte 
keys and corresponding public key certificates, 
and the identifiers of subjects to be certificated 
for which the public key certificates are issued; 
25 and 

either said root registration authority or said 
registration authority holds entity data which 
correspond to the subjects and which Include 
certification data on the subjects. 

30 

6. A public-key-encryption data-communication sys- 
tem according to Claim 1 , wherein: 

the public key certificates each include an elec- 
35 tronic signature field for an electronic signature 

of said public-key-certificate issuer authority; 
and 

a plurality of algorithms are used as a signature 
algorithm forthe electronic signature generated 
^0 in said electronic signature field, and the public 

key certificates each include a field Identifying 
the used algorithm. 

7. A public-key-enciyption data-communication sys- 
^5 tern according to Claim 1 , wherein: 

in data transfer between said public-key-certif- 
icate issuer authority and said root registration 
authority, cross certtfbation processing Is per- 
50 fomned, and when the cross certification Is es- 

tablished, mutual data transfer is executed; 
In data transfer between said root registration 
authority and said registration authority, cross 
certification processing is pertormed, and when 
55 the cross certification is established, mutual da- 

ta transfer is executed; and 
In data transfer between said registration au- 
thority and the subject, cross certifteatlon 



EP1 130 844 A2 



20 



25 



30 



35 



40 



45 



SO 



21 



41 EP 1 130 844 A2 42 



processing is performed, and when the cross 
certification is established, mutual data transfer 
is executed. 

8. A public-key-encryption data-communication sys- s 
tem according to Claim 1, wherein, between two 
among said public-key-certificate issuer authority, 
said root registration authority, said registration au- 
thority, and the subject, data is transferred in a fomri 
in which said data includes a generated electronic io 
signature of a data transmitting side. 



13. A public-key-encryption data -communication sys- 
tem according to Claim 1, wherein said root regis- 
tration authority controls a plurality of system hold- 
ers which provide or manage an infrastructure for 
distributing different contents or services, receives 
a public-key-certificate issuing request via one of 
the system holders from one of at least one service 
provider and at least one user terminal which are 
under the control of the one system holder, and re- 
quests said pub lie- key-certificate issuer authority to 
issue a public key certificate. 



9. A public-key-enciyption data-communication sys- 
tem according to Claim 1 , wherein at least one of 
sard root registration authority and said registration is 
authority possesses a revocation list concerning 
public key certificates corresponding to subjects 
which are under the control of said at least one, ex- 
ecutes the updating of said revocation list, and re- 
quests said public-key-certff k:ate issuer authority to 20 
perfomn data processing corresponding to the up- 
dating. 



14. A public-key-encryption data-communication sys- 
tem according to Claim 12, wherein: 

under the control of said system holder, said 
system holder has contents creator which per- 
fomns provision of contents by using a distribu- 
tion infrastructure for contents or a service.pro- 
vided or managed by said system holder; and 
said system holder treats said contents creator 
as a subject to be certifrcated. 



10. A public- key-encryption data-communication sys- 
tem according to Claim 1 , wherein at least one of 
said root registration authority and said registration 
authority requests the Issuance of a plurality of pub- 
\ic key certificates corresponding to a plurality of 
servtees which are under the control of the one au- 
thority. 

11. A public-key-encryption data-communication sys- 
tem according to Claim 1 , wherein: 

the public key certificate includes a common 
electronic signature of said public-key-certifi- 
cate issuer authority which issues the public 
key certificate; and 

one of a root registration authority, a registra- 
tion authority, a service provider, and a user de- 
vice which perform processing for the verifica- 
tion of one public key certificate issued by said 
publfc-key-certificate issuer authority perfomns 
offline processing for the verification of different 
public key certificates issued by a single public- 
key-certificate issuer authority. 

12. A public-key-encryption data-communication sys- 
tem according to Claim 1 , wherein: 

said registration authority Is fonmed as a system 
holder as an authority which provides or man- 
ages a distribution infrastructure for contents 
which are usable by a user terminal, contents 
for use in providing a service, or a service; and 
said system holder controls and treats a service 
provider and said user terminal as subjects to 
be certificated. 



15. A public-key-encryption data-communication sys- 
tem according to Claim 1 , wherein a user device 
which is under the control of a plurality of different 
system holders controlled by a common public-key- 
certificate issuer authority has a public key of said 
common public- key-certificate issuer authority. 

16. A public-key-encryption data-communication-sys- 
tem forming method comprising the steps of: 

requesting, by a subject to be certificated, a 
registration authority to issue a public key cer- 
tificate; 

transferring, from said registration authority to 
a root registration authority certificating said 
registration authority, a public-key-certiffcate 
issuing request from the subject; and 
transferring, from the root registration authority 
to a public-key-certificate issuer authority cer- 
tificating the root registration authority, the pub- 
lic-key-certiflcate issuing request from the sub- 
ject. 

17. A public-key-encryption data-communication-sys- 
tem forming method according to Claim 1 6, where- 
in: 

said root registration authority treats a plurality 
of registration authorities as subjects to be cer- 
tificated; and 

each of said plurality of registration authorities 
treats, as a subject to be certificated, one of at 
least one service provider, at least one user ter- 
minal, and at least one user whteh are under 
the control of the registration authority. 
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18. A public-key-encryption data-communication-sys- 
tem fomiing method according to Claim 16, wherein 
said registration authority or at least one sen/ice 
provider which is under the control of said registra- 
tion authority applies, to a plurality of different serv- 
ices, a public key certificate corresponding to a sub- 
ject to be certificated which is under the control of 
said registration authority or of said at least one 
service provider which is under the control of said 
registration authority. 

19. A public-key-encryption data-communication-sys- 
tem forming method according to Claim 1 6, where- 
in: 

said root registration authority includes, as one 
of a plurality of registration authorities as sub- 
jects to be certificated which are under the con- 
trol of said root registration authority, a clearing 
center for executing settlement processing; 
and 

in processing using a public key certificate 
which is issued via said clearing center, settle- 
ment is perfonmed which relates to a service 
provided by a registration authority other than 
said clearing center which is under the control 
of said root registration authority or by at least 
one service provider which is under the control 
of said registration authority other than said 
clearing center 

20. A pub lie- key-encryption data-communication -sys- 
tem f omning method according to Claim 1 6, where- 
in: 

said public-key-certificate Issuer authority 
holds a list of the correspondence among public 
keys and corresponding public key certificates, 
and the identifiers of subjects to be certificated 
for which the public key certificates are issued; 
and 

either said root registration authority or said 
registration authority holds entity data which 
correspond to the subjects and which include 
certification data on the subjects. 

21. A public-key-encryption data-communication -sys- 
tem fonming method according to Claim 1 6, where- 
in: 

in data transfer between said publb-key-certrf- 
icate issuer authority and said root registration 
authority, cross certification processing is per- 
formed, and when the cross certification is es- 
tablished, mutual data transfer is executed; 
in data transfer between said root registration 
authority and said registration authority, cross 
certification processing is performed, and when 



the cross certification is established, mutual da- 
ta transfer is executed; and 
in data transfer between said registration au- 
thority and the subject, cross certification 
5 processing is performed, and when the cross 

certification is established, mutual data transfer 
is executed. 

22. A public-key-encryption data-communication-sys- 
10 tem forming method according to Claim 1 6, where- 
in, between two among said public-key-certificate 
issuer authority, said root registration authority, said 
registration authority, and the subject, data is trans- 
ferred in a form in which said data includes a gen- 

15 erated electronic signature of a data transmitting 
side. 

23. A public-key-encryption data-communication-sys- 
tem f omning method according to Claim 16, wherein 

20 at least one of said root registration authority and 
said registration authority possesses a revocation 
list concerning public key certificates corresponding 
to subjects which are under the control of said at 
least one, executes the updating of said revocation 
25 list, and requests said public-key-certificate issuer 
authority to perform data processing corresponding 
to the updating. 

24. A public-key-encryption data-communication-sys- 
30 tem f omning method according to Claim 1 6, wherein 

at least one of said root registration authority and 
said registration authority requests the issuance of 
a plurality of public key certificates corresponding 
to a plurality of services which are under the control 
35 of the one authority. 

25. A public-key-encryption data-communication-sys- 
tem forming method according to Claim 16. where- 
in: 

40 

the public key certificate includes a common 
electronic signature of said public-key-certifi- 
cate issuer authority whteh issues the public 
key certificate; and 

^ one of a root registration authority, a registra- 

tion authority, a sen^ice provider, and a user de- 
vice which perform processing for the verifica- 
tion of one public key certificate issued by said 
public-key-certificate issuer authority perfomris 

50 offline processing forthe verification of different 

public key certificates issued by a single public- 
key-certificate issuer authority. 

26. A public-key-encryption data-communication-sys- 
55 tem forming method according to Claim 1 6, where- 
in: 

said registration authority is fomned as a system 
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holder as an authority which provides or man- 
ages a distribution infrastructure tor contents 
which are usable by a user terminal, contents 
for use In providing a service, or a service; and 
said system holder controls and treats a service s 
provider and said user temninal as subjects to 
be certificated. 

27. A public- key-encryption data-communication-sys- 
tem forming method according to Claim 26, wherein io 
said root registration authority controls a plurality of 
system holders which provide or manage an infra- 
structure for distributing different contents or serv- 
ices, receives a public-key-certificate issuing re- 
quest via one of the system holders from one of at *5 
least one sen/Ice provider and at least one user ter- 
minal which are under the control of the one system 
holder, and requests said public-key-certificate is- 
suer authority to issue a public key certificate. 

20 

28. A publte-key-encryption data-communk;ation-sys- 
tem forming method according to Claim 26, where- 
in: 

under the control of said system holder, said 25 
system holder has contents creator which per- 
fomns provision of contents by using a distribu- 
tion infrastructure for contents or a service pro- 
vided or managed by said system holder; and 
said system holder treats said co ntents creator 30 
as a subject to be certificated. 

29. A pub lie- key-encryption data-communication -sys- 
tem fonming method according to Claim 26, wherein 

a user devfce which Is under the control of a plurality 35 
of different system holders controlled by a common 
publk;-key-certificate issuer authority has a public 
key of said common public-key-certrficate issuer 
authority. 



45 



50 



55 



24 



EP1 130 844 A2 



FIG. 1 
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FIG. 2 
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FIG. 5 
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FIG. 6 
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FIG. 7 
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FIG. 9 



ITEM 


DESCRIPTION 1 




Vi 


Signature, algorithm 
Identifier 


SIGNATURE ALGORITHM 


ELLIPTIC CURVE 
ENCRYPTION/RSA 


Issuer 


REVOCATION LIST 
ISSUER NAME 


NAME OF THE lA 


Tiiis Update 


ISSUANCE DATE AND TIME 
OF REVOCATION LIST 




Next Update 


NEXT ISSUANCE DATE 




V2 


Version 


VERSION 




Authority key indentifier 

Key Identifier 

Auttrority Cert Issuer 

Authority Cert Serial 
Number 


CERTIFICATE IDENTIFIER TO 
BE USED FOR SIGNATURE 
VERIFICATION 

KEY IDENTIFICATION NO.(OCTAL) 
lA NAME (General Name FORM) 
CERTIFICATE NUMBER 




CRL Number 


SERIAL NO. OF REVOCATION 
LIST 




Issuing distritHition point 


PROPERTIES OF REVOCATION 
LIST DISTRIBUTION AUTHORITY 

DISTRIBUTION AUTHORITY NAME 
(GN FORM) 




Distribution poin 

Only contains user certs 


•TRUE" FOR DEDICATEDUSE OF 
SUBSCRIBER REVOCATION 

•TRUE- FOR DEDICATED USE 
OF CA CERTIFICATE REVOCATION 




Only contains CA certs 


INFORMATION SUCH AS 
REVOCATION REASONS CAUSED 
BY SOME REASONS IS SENT NOT 
TO REVOCATION LIST ISSUER 




Only some reasons 


AUTHORITY BUT TO CERTIFICATE 
ISSUER AUTHORITY " 




indirect CRL 






DeltaCRLindicator 


INDICATES WHETHER REVOCATION 
LIST IS DIFFERENTIAL • 





33 



EP1 130 844 A2 



FIG. 10 
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